【正文】 are samples. This implies that anomaly based detection is still indispensable.Behaviorbased intrusion detection systems (IDS). These systems rely on predefined rules to detect anomalies in the runtime system behavior. They can better detect zeroday attacks that attempt to evade codebased signatures. But, getting the rules right can be difficult and therefore the rules tend to be relatively coarsegrained. For example, by default, McAfee Virus Scan Enterprise [5] Access Protection rule blocks outbound port 25 to filter malicious programs. However, to get normal applications to work, 42 popular clients, such as and [11], are exempt. Note these applications are often the ones exploited.3 MethodologyIn this section, first we present highlevel methodologies used in Ensemble, then explain them in detail in 167。 to 167。. The goal of Ensemble is to detect application misbehavior, particularly caused by zeroday attacks. As the start point of our approach, we generate a local profile for each application instance. A profile is a summary of target application’s interprocess munications and its behavior that can result in persistent changes(changes that survive across reboots) to the file system, the registry, network, and other system settings. They are abstracted from system call traces. Statistically, it can be seen as representative data points in the sample space containing all possible state changing behavior of the target application. We envision that a large number of munity users feed local profiles of an application to a central server, which periodically aggregates them into a global profile, depicting the application’s normal behavior as a baseline. The global profile serves as a classifier that identifies anomalies using collected local profiles as training data.Ensemble: CommunityBased Anomaly Detection for Popular Applications 167.To detect and prevent intrusion, we monitor the application behavior and pared it with the global profile alarm is triggered when the application is about to perform an operation that does not match the global profile. The user can be alerted or the system can be configured to directly block the operation. Next we investigate several important challenges of our methodology. Profile Generation Local profiles. A local profile is generated from raw system call traces [26]. In Windows,system calls are undocumented, thus we use Windows API calls in our simplicity we ignore a set of APIs that do not modify host file system or network state such as graphics and user interface API that are unlikely abused or even if abused will likely be visible through other APIs we monitor. Also, we only focus on operations executed by the target application given the profile is for a particular application, with the exception of the process dependency, as discussed below.Global profiles. A global profile is distilled from multiple local profiles. We develop a taxonomy for APIs in terms of functionality (process dependency, file access, network access, etc.). For each category, corresponding records in local profiles are aggregated by key attributes (Table 1). An example of aggregating File Access category is shown in Table 2.Table 1. Key attributes for primary categories in global profilesCategory Key Attributes,Process Src Process Name/Image Hash,Dependency Dst Process Name/Image Hash, Type ∈ {Fork, Hook, File...}File Access Filename, Type ∈ {Read, Write}Registry Access Registry key, Type ∈ {Read, Write}Network Remote IP, Remote Port,Connection Protocol ∈ {TCP, UDP, other}Table 2. Example: aggregate records in local profile (a) into global profile (b)(a) Local profilesProfile ID Filename Bytes accessed Type1 10 read1 15 read1 10 read2 10 read(b) Global profilesFilename Type Count by profiles read 1 read 2Among all the categories, the process dependency [29] depicts the interaction among processes of the target application and other processes. A local profile contains two types of dependencies: indirect and direct dependency. Indirect dependency, such as a file dependency (Process A writes file F, which is then read by Process B), requires an 168 F. Qian et al. object (., a file or an IP address) as an intermediary. It is synthesized by correlating multiple API calls. Direct dependency, such as a fork dependency, takes place without an intermediary. It can be inferred from a single API call. The Environment Diversity ChallengeFor categories other than process dependency, the simplified methodology illustrated in Table 2 has limitations. For example, for a text processor, different users edit different files, thus the file access category is not aggregateable if naively using the filename as the key attribute. Similarly, a P2P client may talk to random IP addresses, leading the aggregation in the global profile to be a set of IP addresses each with very few occurrences. We apply two methods to address this challenge. First, we use predefined rules to normalize the path and file names. For example, c:\Documents and Settings\Alice\ is normalized to USERDOC\. This also helps protect the privacy of munity users. Second, our main solution is Stack Signature, which describes the stack history of the calling thread for each API call. The key idea is that the “random” events of the same functionality of a program such as sending a message or making a VoIP call in Skype, should be associated with a fixed set of execution paths that can be represented by call stacks. Based on this assumption, we introduce Stack Signature, a pact version of call stack. A Stack Signature is calculated by iterating all stack frames of the current thread and XORing their return addresses. In the case of recursive calls, return addresses occurring multiple times are counted once. In a global profile, the relationship between stack signatures and objects (., filenames and IP addresses) can be characterized by a weighted bipartite graph, who