毕业翻译电信计算机.doc

本科毕业设计外文翻译外文译文题目（中文） ：系综：以社区为基础的流行应用程序的异常检测学 院:信息科学与工程学院专 业:电子信息工程学 号:200904135138学生姓名:陈杰指导教师:陈建良日 期:2013-5-8Ensemble：Community-Based Anomaly Detection for Popular ApplicationsFeng Qian, Zhiyun Qian, Z. Morley Mao, and Atul PrakashUniversity of Michigan, Ann Arbor MI 48109, USARobustNet Research Group系综：以社区为基础的流行应用程序的异常检测冯倩，钱志云，Z.莫利毛，阿图尔普拉卡什 密西根大学安娜堡分校（密歇根州 48109），美国乐百氏网研究小组系综：以社区为基础的流行应用程序的异常检测摘要：保卫终端用户系统的一个重大的挑战是流行应用程序存在运行时被劫持的风险。由于传统代码本身是一成不变的并且局部异常探测器由于训练数据不足难以调整为正确的阈值，传统的措施很难阻止这些威胁。考虑到被攻击目标的通常是受欢迎的进行交流沟通和社交网络的应用程序，我们提出一个新颖的、自动化的方法，系综，它是基于调用应用的本地的行为概要文件给一个全球概要文件合并引擎的社区用户信任的免费系统。这种信任可以被认为 存在于企业环境和可以进一步监管声誉系统中。例如，通过利用社交网络中固有的信任关系。这些生成的全球配置文件可以被所有社区用户用来对当地异常进行检测和预防。基于57个恶意软件的评价结果清楚说明系综是一种能够在企业环境中有效的防御约300或更多的用户的技术。1 介绍由于多种多种原因终端用户系统很难确保安全。他们是典型的非托管：用户疯狂的下载软件、上网等等。在本文中，我们主要讲解受欢迎的应用程序在运行时被劫持攻击的防御。在过去，这些劫持已经导致了广泛的攻击，如Skype的蠕虫通过使用Skype和缓冲区溢出在Outlook电子邮件客户端传播执行任意代码。传统的措施，例如杀毒扫描器，不能阻止这些威胁，因为应用程序代码本身是未修改的。以前的工作表明，系统调用层次剖析可能有助于检测这样的攻击，但一个重要的障碍是早期缺乏足够的训练数据，确保低误判率。在本文中，我们提出一种新的无监督整体异常检测方法，基于的理念是一个值得信赖的社区的用户贡献本地应用程序配置文件给一个共同的合并引擎系统调用。全球概要文件可以用来在每一台终端主机上的应用程序行为中进行实时异常检测或防御。这种方法的承诺是，它有助于克服在每个主机上缺乏足够的训练数据问题，很大程度上的可以实现自动化。面临的挑战是要制定这样一个的系统效率，克服在概要文件由于如安装目录或硬件的变化因素形成的分歧并确定适当的信息收集在概要文件。潜在的假设集合是，随着数量的本地配置文件增加，全球总体轮廓往往收敛，从而揭示了正常行为的目标应用程序。尽管我们确定在部分类型的应用程序会出现异常，但我们发现实验中大多数应用程序满足这个属性。本文作以下方面的讨论。处理执行环境的多样性。基于社区的各种因素影响剖析，例如，同一个应用程序在不同的主机上可以安装在不同的目录中，在不同数量的内存中运行，甚至使用不同数量的cpu。所有这些因素都会导致在系统调用跟踪他们的参数引起变化。我们确定类型的数据用于生成行为概要文件来处理这些变化，同时保持概要文件应用程序的紧凑和代表。社区规模和假阳性利率之间关系的分析。我们首先应用基于社区的异常检测到一个社区的12个用户使用正常，干净的即时消息应用程序。详细的系统调用级别数据是在5个小时中抽取50分钟的采样数据，每一分钟的采样数据在局部剖面基础上生成。我们发现，假阳性高费率将重点关注中，就像使用单一主机分析使用系统调用。一个试验台虚拟机被用于研究的影响扩大到一个更大的系统的用户社区。我现发现，一般来说，技术会变得更加有效和适合更大的社区。在观察在达到大约300用户后我们发现误判率显著减少。技术通过分析应用程序生成分享总汇数据来减少数据传输。我们发现当每个主机收集详细的系统调用级数据提供给局部分析时，它只需要发送一个适度的本地配置文件数据/应用程序(大约4 - 5 KB /秒)到一个共同的服务器来创建社区的文件。一个通用的接口。我们的系统提供了一个有用的抽象接口来使得任何目标应用程序得到保护。多个应用程序可以订阅系综服务。在Windows中的系综是目前在用户空间实现。我们采用迂回库27微软研究院拦截系统调用为目标的应用。为提高效率，讨论4.2，系综可以作为一个服务的操作系统的内核来实现。接下来的文章组织如下:2概述相关工作;3描述了整体模型的系综;4实现我们的细节;和5评估系统实验。最后，6结束前的讨论局限性7结束。2 相关工作我们的工作，提高现有的工作，在异常检测领域的探索以社区为基础的分析，生成详细的运行时行为的适用性在系统调用级别的应用程序的配置文件。下面我们将重点介绍一些相关的在恶意软件检测和遏制方法。异常检测。第一个研究应用程序异常检测是福里斯特等。他们多次执行一个程序用不同的输入来收集系统调用序列，然后使用这些形成基线行为的程序。任何重大偏离基线被认为是一个异常。许多后续的研究包括机如隐马尔可夫模型和神经网络的学习技术。后来的研究研究纳入的系统调用参数，调用堆栈信息。生成通用模型从不同的运行是一个比较复杂的问题。在Ballardie和crowroft探索几种典型模型，包括基于频率的数据挖掘模型的方法，和一个有限状态机的方法。所有以上方法能承受高的假阳性率。他的数据收集过程通常是手动或可能需要很长时间才能覆盖大多数正常的行为。如果应用程序的正常行为并不充分捕获的，未被注意的正常行为是可能的错误归类为不正常。虽然更好的机器学习算法，可以帮助解决一个很难获得足够的训练数据去捕捉到全面的应用的行为而使这些计划的实际根本的问题。我们的工作是建立在上述系统中的方法。主要的贡献是要表明，如果广大的用户群体分享他们的培训与IDS的数据在细粒级，行为可以生成更完整的配置文件和准确的本地配置文件。我们在社区环境延长审查技术的其中一个挑战不只是投入问题，而且经营软件的环境可以是不同的。在我们的实验中，我们允许应用程序被安装在不同的硬件配置各种系统随机目录和不同工作负载施加的其他应用程序。我们结合配置文件来处理可能的变化扩展现有的算法。以社区为基础的系统。“应用社区”这个概念的提出了通过生成适当的配置补丁和过滤器对于协同诊断和应对攻击。系统目标是生成一个会提供对基层社区适用情况来预测即将到来的攻击意识。不过，这并不专注于在我们的工作中检测异常来帮助防止攻击。一个类似“协作学习为安全”的概念应用于自动生成的一个问题软件补丁而不影响应用程序的功能。然而，探测器使用的是静态的探测器没有训练的方式，以及社区利用仅限于收集详细的执行限制在二进制，分布生成的补丁，并让用户社区评估他们。像赛门铁克，微软和谷歌这些公司还利用基于用户识别恶意软件程序或垃圾邮件反馈意见为概念社区提供帮助。治安维持会成员和清洁工试图通过自动检测利用控制互联网蠕虫。都允许一个用户在社区分享他们的抗体，预防和制止未来互联网蠕虫的攻击。在其他应用程序上下文，社区的概念也会被探索。同行压力利用通过假设大多数用户在社区有正确的配置它来自动检测和排除错误配置。伽马系统提出了把监控任务在社区用户，使最小程度的程序分析和软件进化。同样，合作社问题隔离利用社区去做基于由社区用户反馈数据自动生成的“统计调试”。与上面的身体工作相比，我们在更细粒度级别的社区的工作检查的有效性的概念应用。而不是仅仅相结合进位反馈或签名的蠕虫病毒，我们整合了运行时的行为概况，包括整个社区的系统调用和相关参数，应用异构的用户。这允许我们增加额外的软件应用程序类的异常检测。基于签名的防病毒软件。在这种方法中，用户通常使用一个已知的攻击特征数据库，导致误报的优势可以忽略不计。不幸的是，很难保持签名覆盖新的袭击。一项由Oberheide 等公司的调查发现商业杀毒软件在过去一年攻击发生检测率只在54.9%至86.6%不等的范围内。更重要的是，杀毒软件对最近的恶意软件样本检测率明显较为贫穷。这意味着基于异常检测仍然是不可或缺的。基于行为的入侵检测系统(IDS)。这些系统在其运行时依赖于预定义的规则来检测异常行为。他们可以更好的检测试图逃避基于代码签名的零时差攻击。但是，获得正确的规则是很困难的，因此规则往往是相对粗粒度。例如，在默认情况下，McAfee病毒扫描企业8.5i版访问保护规则块出站端口25过滤恶意电子邮件程序。然而，为了获得正常的电子邮件应用程序，42个流行的电子邮件客户端，如Outlook.exe和thunderbird.exe，可豁免。请注意这些应用程序往往是那些刻录软件。3 方法 在本节中，我们首先提出高层次的乐团中所使用的方法，然后解释详细在3.1 到3.3中.整体的目标是检测应用程序行为，尤其是零时差攻击造成的。作为起始点我们的方法，我们为每个应用程序实例生成一个本地配置文件。配置文件是一个目标应用程序的总结单独进程间通信其行为，可能导致在（变化，生存在重新启动后）的文件系统，注册表，网络和其他系统设置持续变化。他们是从系统调用的痕迹中抽象出来的。据统计，它可以被看作是在样本空间包含目标应用程序的行为的所有可能的状态变化的代表数据点。我们的想法是，大量的社区用户本地配置文件应用程序的定期聚集成一个作为基线来描述应用程序正常行为的全球的资料的中央服务器。全球剖面作为分类器把收集到的本地配置文件作为训练数据来识别异常。我们随着全球概要不断地监控应用程序的行为检测和防止入侵。应用程序将要执行不符合全球概要的操作时报警就会触发。可以提醒用户或配置系统来直接阻止操作。接下来我们探讨我们的方法面临的几个重要挑战。3.1 配置生成本地配置文件。本地配置文件是来自原始系统的调用跟踪。在Windows中，系统调用是非法，因此我们使用Windows API调用在我们的原型。为简单起见，我们忽略一组API不修改主机文件系统或网络状态，如图形和用户接口API，它不太可能滥用或者甚至认为在滥用我们监控的其他API中是可见的。与此同时，我们只专注于业务目标应用程序为特定的应用程序给定的执行概要文件，除了流程依赖关系，如下面所讨论的。全局配置文件。全球的资料是从多个本地配置文件提取精炼出来的。我们为api在功能方面(过程依赖、文件访问，网络访问等)开发了一个分类法。对于每个类别，对应的记录在本地配置文件聚合的关键属性(表1)。一个例子的聚合文件访问类别显示在表2。它是通过相关的多个API调用合成。直接依赖，比如一个叉依赖，没有发生一个中介。它可以从一个单一的API调用推断出。3.2 环境多样性的挑战对于分类除了流程依赖关系外，表2中简化方法有一定的局限性。例如，对于一个文字处理器，不同的用户编辑不同的文件，然而如果天真地使用文件名作为关键属性，档案存取类别不可聚会的。同样，一个P2P客户端可能跟随机IP地址，导致聚合在全局配置文件是一组用的很少的事件的IP地址。我们应用两种方法来解决这一挑战。第一种，我们使用预定义的规则规范化路径和文件名。例如，c:Documents and SettingsAlicea.dat is normalized to USER-DOCa.dat.这也有助于保护社区用户的隐私。第二种，我们的主要解决方案是堆栈签名，它描述了堆栈调用每个API线程的历史。该方法的核心是相同的功能的程序的“随机事件”，如在Skype中发送消息或制作一个VoIP呼叫，应该被关联到一个固定可以调用堆栈的执行路径。基于这样的假设，我们介绍堆栈签名，一个紧凑版本的调用堆栈。一个堆栈签名是由所有当前线程的迭代计算和他们的返回地址进行异或运算的堆栈帧。对于递归调用，多次发生返回地址被算为一次。在全球的资料文件，堆栈之间的关系和对象(如签名、文件名和IP地址)，其特征是一个加权偶图，其顶点分为两个不相交的集X和Y，其中X是套堆栈签名和Y是一组对象。有一条边e：x ye 当x X和yY，当且仅当一个事件访问对象y有堆栈签名x在至少一个当地的形象。每个元素在X，Y和E的权值，表明其在当地档案发生频率的数量。除了流程依赖关系是相当稳定的，我们为所有其他类别介绍堆栈签名和使用由两部分构成的图形作为其数据抽象。我们看到很多这样的例子在我们的实验。例如，在堆栈x61ae46f8，QQ，一个即时消息应用程序,从至少64个不同的服务器可以通过端口8000接收数据，如121.14 . *.*，219.133 . *.*，58.61 . *.*。所有服务器都发现在QQ总部所在地的中国广东。接收的数据的大小一直是一个10240字节的倍数。3.3 异常检测作为开头提到的这部分，系综客户定期把全球概要文件从服务器。异常检测和预防的不断进行。每个操作之前执行监控系综，API调用被拦截，并与全球概要文件使用以下比较算法。（1）基于阈值过程的依赖异常检测如果一个过程依赖D检测(如一个叉或文件依赖)，我们找到它的频率f(D)=#本地配置文件包含D #本地配置文件。在全球的资料文件中，如果f(D) thPD，thPD是一个阈值，那么D被视为异常。（2）堆栈特征分析如果操作执行的目标程序不属于在表1其他类别，那么它的栈签名的计算，其对象x是计算，y是识别，和e:xy是与在全局配置文件的偶图BG = XG，YG 匹配的。让e和x的频率在BG分别为f(e)和f(x)。(即，f(e)= #本地配置文件包含e #本地配置文件)。我们还将介绍阈值the，thx 和degx.。我们确定e是一个异常的行动由几个测试寻找可预测的关系的对象访问栈签名。4 实现我们的系综的架构原型如图4所示。它是通过使用不断更新全球概要文件和生成的本地配置文件来设计执行网络异常检测。现有的工作主要是在Linux环境的评估，然而我们的系统是要在微软Windows XP系统这一更常见的攻击目标上实现的。我们会使用约10000行C + +代码来实现原型。在我们的设计中，为代表的当地概况，我们最初试图利用系统调用序列(n元语法之前建议，由于其声称有效性和简单性。然而，我们发现，语法已经惊人地低为Windows API序列收敛速度方面获得应用程序的正常行为模式，很可能因为一个比在Linux更大的样本空间(Windows API的数量是Linux系统调用的6倍数量)实现系综。我们估计有两个原因造成这样大的差异：其一，有明显差异Unix / Linux系统调用和Windows api；其二，现代应用程序变得越来越复杂。系统调用可能是太找到粒度表征程序行为。注意，很多研究人员对病毒或恶意软件应用n元算法，其二进制大小远低于合法应用程序。因此，我们采取了3.1中描述基于频率的有一个更快的收敛行为的简单模型。4.1 生成配置文件和异常检测我们使用迂回库监控和记录106编程接口调用相关文件系统、注册表、文件映射、消息、线、过程、网络、管、钩、剪贴板、系统时间、DNS、处理管理和用户帐户管理，其中大部分是Windows特定的。我们所掌握的最好知识，他们覆盖大多数可以导致进程间通信的编程接口，或导致持久文件系统、注册表、网络和其他系统设置的变更。注意，新的编程接口加入框架是相当容易的。我们在Windows调试库中使用StackWalk64函数生成堆栈签名。考虑到原始API跟踪及其堆栈签名，生成在3.1(对于流程依赖关系)和3.2(对于其他类别)中所述的本地配置文件。我们实现了七类配置文件。(1)流程依赖关系型，(2)文件访问型，(3)目录索引型，(4)目录访问注册表访问型，(5)网络连接型，(6)DNS型，(7)IP前缀访问型。我们处理4类型的直接过程依赖关系：发送信息，设置钩，创建/终止/中止进程(线程)和写/读/分配/ 释放进程内存，以及8种间接依赖关系:文件、注册表、文件映射、网络、命名管道、匿名管道、系统时间和剪贴板。API是平凡地通过翻译API参数转换到其他类别(例如痕迹、文件访问、网络访问)的。全球概要文件经过对各种本地配置文件分组生成。除了由如表2(b)代表的流程依赖关系，其他类别使用由两部分构成的图表(堆栈签名对象名称)作为代表。我们在3.3描述的异常检测算法是非常有效的。4.2 操作模型最后，我们提供了一个概述的系综的操作模型。在每个客户端，总体运行作为一个系统服务和目标应用程序是透明的。验证码是用来防止机器人篡改系综当订阅或取消订阅服务的。当应用程序正在运行，总体抽样模块定期记录它的API调用堆栈签名并生成与本地配置文件(如，每3个小时，利用API调用痕迹的一分钟抽样生成一个本地配置文件)。整体通信模块定期提交本地配置文件到服务器，同时从中提取全球概要文件。系综异常检测模块保持监控目标应用程序的API调用并将他们与全球概要进行匹配。如果警报被触发，所请求的操作会被拒绝，否则决定权留给用户自己。最初我们的异常检测是抽样的：当地一个概要文件生成定期并与全球概要文件比较。然后我们发现，即使是不断进行异常检测，额外的开销也是可以接受的(小于2%)，因为在大多数情况下，应用程序的API调用不调用“丛发性”的方式。系综服务可以大规模进行维护(如通过应用程序供应商)，或小范围的维护(如在企业网络)。其任务包括收集本地配置文件，生成全局配置文件和其他管理功能。理想情况下，每个版本的应用程序应该有自己的全球形象。对于特定的应用程序，一个全局配置文件也可以描述几个有轻微差异的版本。4.3 原型的限制我们目前的原型具有不是基本为我们的设计以下限制。在客户端，采样模块是使用第三方库在用户级别实现。对于未来的工作，我们计划将整个系统嵌入Windows内核。在服务器端，为防止污染的全球配置文件，我们将调查建立在社区用户之间的信任之上的声誉系统的使用。目前，我们设想我们的的系统，主要被部署在企业环境中，而在那里信任可以被假定。最新款Windows Vista的采用了地址空间负载随机化的（ASLR）技术，这妨碍了栈的签名功能。 我们可以通过使用从模块的起始地址相对偏移的返回地址连同模块签名解决这个问题。5 评价和实验在本节中，我们系统地评估系综。首先，我们描述一个小规模部署为一个社区的12个用户(5.1)。基于负面结果由于尺寸受限制的社区，我们介绍我们的试验台和用于实验的目标应用程序(5.2)，然后分析生成的本地配置文件(5.3)和由此产生的全球配置文件(5.4)。接下来，我们测量假阳性(5.5)最后我们提出我们的系统的性能评价(5.6)。5.1 小型真正的部署我们部署的系综在12个真实用户中，使用Windows Live Messenger(MSN)为目标应用程序。所有用户用不同的软件和硬件配置在使用Win XP SP2。在实验前，我们手动升级他们的MSN到同一版本(版本号：2008Bulid 8.5.1302.1018)，并确保无病毒的系统。用户不熟悉技术细节的系综，并被告知需要像往常一样使用MSN。对于每个用户，在一个5小时的时间内，我们收集了50个API调用的痕迹，每一次持续1分钟。我们使用此数据集评估假阳性。我们曾经在600条痕迹中用5倍交叉验证评估假阳性。在每个追踪测试组，如果任何API调用触发一场虚惊，那么当地的形象被算作一个假阳性。当参数为3.3中值，实证性地设置the = 1%，thx = 1%，degx = 10，winSize = 4 kb(我们尝试了不同的参数，例如 2%，thx 2%，degx 20)，并得到了类似的结果。我们发现假阳性利率过高将难以被接受(大于30%的文件访问和注册表访问)。原因是12个用户并不足以形成一个社区，覆盖不同应用程序的行为。5.2 实验基础设施未了测试在一个更大的社区中的影响，我们创建了一个自动化测试平台来模拟一个社区环境。想法很简单：目标应用程序执行多次在试验台。在每次执行时，当地的一个概要文件创建和美联储全球概要发生器，仿佛这是一个真实的社区提交的用户。然后我们使用全局配置文件来对正常和异常行为进行测试并评估假阳性和否定。我们的试验台有两个设计目标。多样化的用户行为。随机用户行为是注射在每个试验中。分布的随机性应该大致符合一个真正的社区。多样化的系统环境。在每个试验中，系统环境也应该用不同硬件和软件来模拟一个真实的社区变化。例如，一个VoIP客户可能根据可用的网络带宽调整其语音编码策略，导致产生不同的本地配置文件。我们手动创建一个有限状态机(FSM)为每个目标应用程从一个终端用户的角度序来描述它的大部分主要功能。有限状态机(FSM)可以产生在一个更加自动化的时尚结合用户跟踪和添加一些扰动包括额外的使用行为。尽管手动工作，有限状态机(FSM)是基于理解应用程序的使用的代表，甚至近似可以帮助对于一个给定的应用程序产生更多样化的使用场景。图5是一个简化的FSM的MSN。在每一个自动执行中，试验台基于马尔可夫链模型进行部分迭代FSM，它描述了流行的应用程序的不同功能。每个状态转换SxSy在FSM代表一个用户操作。权值e是给定当前状态是Sx，指示下一个状态是Sy的概率。例如，在图5中，“登录”是用户启动应用程序的初始状态。用户成功登录(101 + 2 + 10 = 77%)的概率远高于用户输入一个无效ID或密码(8%)的概率。这个试验台不仅随机选择了行动，同时也执行了一些随机性操作。例如，它可以在一个即时通讯的，选择一个随机的用户，和他/她聊天通过随机短信、情感图标，手写字或Flash使眼色。在另一个例子，“电话行动”在Skype中从我们收集到的3000免费电话号码进行拨一个号码。图5是一个简化的有限状态机的MSN。边缘上的标签显示状态转移概率。我们承认我们的方法包含主观元素和因此可能不完全模拟一个社区环境。然而，一个社区本身是一套主观用户，并倾向于随时变化。同时，我们将在5.3展示用户的行为的重尾分布的模拟，这是通常情况下在一个真正的社区。应对系统环境随机性，试验台为每个实验自动变化的硬件/软件配置。为便于管理，所有的实验是在虚拟机(VMware 6.0.2)进行的。不同的配置包括内存、处理器数量安装软件，现有的运行过程、系统负载、防火墙设置，系统时间、网络带宽、DNS服务器等等。FSM的试验台包括一个脚本解析器，一个行动执行人，负责维护状态同步和发送鼠标/键盘输入到目标应用程序，配置机械手，改变系统环境和传播者，与系综的内核。这个试验台是建立在使用约3000行C + +代码的基础上的。我们在微软Windows XP SP2上选择了四个应用程序作为我们最初的目标应用程序：skype （3.5.0.239版）；Windows Live Messenger(MSN) （2008bulid8.5.1302.1018版）；Tecnet QQ(2007 Beta 4，7.0.374.204版)，一个在中国通常的超过3000万在线用户的ICQ客户端；Serv-U（5.0.0.0版），一个贸易FTP服务器。这些应用程序被选中是因为他们过去的声望和他们被瞄准攻击的历史。5.3 本地配置文件表3显示了本地配置文件的数量、取样时间和API记录的每个目标应用程序的本地配置文件的大小。采样时间设置为符合高斯分布。抽样过程无论是在应用程序启动或启动之后一，又或是在应用程序终止之前或已经停止都可以开始。整个收集当地档案持续了一个星期。如前所述，我们在每个试验中模拟不同社区的用户行为而创建了随机性。因此每个用户可能探索的不同子集的应用程序功能。图6为Skype，MSN和QQ说明了FSM的分布模式。一个模式在一个试验定义了状态迭代的测试平台。如果有n可能状态在有限状态机(FSM)，然后有2 n1可能的模式(0，0，0，1)，(1，1，1，1)。对于模式(a1，a2，an)，ai = 1的状态下，i-th 在一个试验中至少被访问一次。从我们的试验台产生图6展示的重尾分布的用户行为多样性，以及大多数用户的相似行为。虽然这可能不是完全匹配实际的用户行为，但我们相信只要我们的方法添加足够的随机性就可以密切近似一般用户活动。5.4 全球概要文件表4展示了统计的全球配置文件。表中的数字是数量的流程依赖关系，对于其他类别，边数在双边的图表中。这个过程依赖类别的QQ，MSN和 Skype分别如图9(a)、10和11(a)。只有部分与实线代表观察到的依赖关系。边缘上的百分比表示其发生的频率。由两部分构成的图形的大小通常是更大的。图7显示了由两部分构成的图的例子。对于每个子图，上部X是套堆栈签名;下部Y是一组由一个号码(对象ID)对象(注册表键，目录名称等等)。在方括号的数字是频率。子图(a)是一种常见的情况下，固定栈签名访问一个固定物体。例如，堆栈签名0 x7bf74721总是读3个注册表键值：REGISTRYMACHINESOFTWAREClassesQQCPHelper.REGISTRYMACHINESOFTWAREClassesCLSID23752AA7.REGISTRYMACHINESOFTWAREClassesCLSID23752AA7.子图(b)演示了一个随机事件的问题。对于每个试验中，堆栈签名1814742014(0 x6c2ac3fe)在REGISTRYMACHINESOFTWAREClassesCLSID 和REGISTRYMACHINESOFTWAREClassesTypeLib 下写不同的注册表键值。子图(c)说明了如3.3中堆栈签名的轻微变动。我们子图(c)可以观察到两个集群的堆栈签名：4582218?，1819194?.两个集群都访问用户cookie目录USER-DOCcookies.图7是一式两份的图的例子。从上到下：(a)注册表写QQ类(b)注册表写Skype类(c)目录写MSN类。5.5 假阳性我们在实际部署(5.1)中使用相同的方法(5倍交叉验证)和参数评估试验台的假阳性。在表5中，列“有限合伙人”表示本地配置文件在测试组的数量;列“最差”和“最佳”分别表明在10个独立实验(每个实验有5个通行证)中最高和最低数量的假阳性(包含至少一个API调用触发虚假报警痕迹)。表6提供了一个细粒度的假阳性测量。与上面类似，我们使用相同的参数重复了十次5倍交叉验证和实验。在表6中，列“Avg E”表示在测试组的API 调用平均数量，送入系综异常检测模块;列“最差”和“最佳”分别表示检测出异常错误的API调用最高和最低数量。对于Skype和ServU，没有假阳性被观察到。对于MSN和QQ，尽管他们的细粒度的假阳性的注册表读取和连接类别小幅上涨，甚至当假阳性率收敛(如图8)，但误检测主要集中在本地配置文件(通过人工观察发现，在这些地方生成配置文件期间，应用程序意外终止是非常可能的)的几个API调用。理想情况下，如果他们确实是应用程序的自然行为，然后随着池的训练数据规模越来越大，最初的“奇怪”的行为将变得正常，大尺寸的训练数据实际上是一个社区的优势。当我们测试Skype，这是产生网络相关行为假阳性利率(在表5和表6中两个类别的假阳性标记为“N / A”)。在手动检查时，我们发现，从相关的api的网络堆栈签名几乎均匀分布在整个地址空间，准确的说，“Avg E”是在偶图中过程依赖的边缘频率或数量。根据我们的估计，Skype可能采用一些模糊技术来针对逆向工程保护他们的代码。总之，我们相信，假阳性的系综是可以接受的。此外，我们使用在实际部署中的600 条API的调用痕迹对由试验台MSN生成的1298条本地文件生成获得的全球概要文件进行测试。我们得到了0%假阳性的比率(过程依赖)，6%(文件读取)，4%(文件写)，2%(目录读取)，1%(目录写)，11%(注册表读取)，6%(注册表写)，9%(连接)和3%(IP前缀)，表5中使用的就是这些值。在手动检查时，假阳性的主要原因是我们的FSM模型不完备，其中一些例如视频聊天的软件都没有包括进去。我们也使用5倍交叉验证测量了社区关系大小和假阳性率的关系，并给出了使用最坏的情况下的结果(在10个独立实验数量最多的假阳性)。如图8所示的三个应用程序，从中可以明确的是，细粒度的假阳性率显著增大，而且随着越来越多的本地配置文件，并收敛于一个稳定值(在本节前面我们讨论了高误报率的QQ和MSN)。一个真正的活跃的社区被认为是由网友上传的具有更大数量级的本地配置文件，从而确保有较低的假阳性率。5.6 绩效评估每个应用程序都有一组“正常行为”(真正的基线)。当探测器定义的正常行为超越真实的基线(即过于宽泛)假阴性就可能发生，因为特性或方法不适当或者说模型并不足够精确(即一个不完美的探测器)。几乎所有实际的id，检测或定义的正常行为是比真正的基线更广泛的，因此允许模仿攻击。这不只是我们探测器的问题，任何探测器都有。聚合过程不应该引入过多额外的通病。当地的概要文件的聚合多样性有以下原因：(i)用户随机性。不同的用户可以生成不同的配置文件，但他们大多属于真正的基线假设概要文件是可信的（用户随机性可以视为在应用程序中使用不同的正常执行路径)。(ii)系统环境的随机性。我们承认不同的系统环境可能有不同的组“正常行为”。然而，如果有的话，应该引入有限的通病。在最坏的情况下，我们可以如4.2中的不同操作系统和软件版本分配单独聚合/池。6 系综的局限性我们发现系综是解决使用运行时配置文件检测代码入侵和其他运行时异常的一种很有前途的方法，并且还能指出在未来需要解决的局限性。我们还发现,一些太复杂的应用程序会局限于使用有限的系统调用抽样。我们的实验表明复杂的插件启用的应用程序会和原来的不一致，如IE插件可能以微软Word来表现。额外的取样和更大的社区可以帮助帮助改变这种情况。我们要在一个真正的社区对数以百计的用户做整体评价。隐私问题必须解决,即便系统只对调用汇总数据与服务器交换。如果一个显著部分社区的用户安装一个协调攻击污染全球概要,可想而知,全球配置文件会被破坏。在开放社区,污染攻击是可能的。在封闭的社区,在企业环境中,这样的攻击是不太可能。不同的应用程序可能需要不同类型的分析。例如,如果一个应用程序在功能或故意随机地址指令级别(例如，5.5中网络接入模块中提到的Skype会混淆这种行为),那么堆栈签名是无效的。可以添加替代方法,如路径分析，来处理这样的应用程序。在我们的设计中,堆栈生成签名的独特的返回地址栈帧。碰撞的概率在32位操作系统是不容忽视的,但在64位的系统中却变得越来越流行。6.1 通病每个应用程序都有一组“正常行为”(真正的基线)。当探测器定义正常行为超越真实的基线过多(即,过于宽泛)；因为特性或方法不适当的或并不足够精确的模型(即,一个不完美的探测器)，假阴性可能发生。然而，几乎所有检测或定义的正常行为是比真正的基线更广泛的,从而允许模仿攻击。不只是我们存在在聚合过程引入过多的附加的通病，任何探测器都存在这样的问题。考虑当地的概要文件的聚合多样性的原因有:(i)用户随机性。不同的用户可以生成不同的配置文件,但他们大多属于真正的基线假设概要文件是可信的(用户随机性可以视为有不同的正常执行路径)。（ii)系统环境的随机性。我们承认不同的系统环境可能有不同的组“正常行为”。然而,这是在任何情况下都应该被限制的通病。在最坏的情况下,我们可以有单独的、如4.2上的不同操作系统和软件版本的聚合池。6.2 模仿攻击一个完美的探测器不应该因为以偏概全而给模仿攻击留下任何机会。注意，聚合过程是用于异常检测的独立的特性或方法。模仿攻击的存在主要是由于受特征选择和检测技术的限制，而不是在于剖面聚合。我们的重点是要指出，我们如何能够用一个合理的探测器减少假阳性而不是使功能丰富达到足以排除的模拟攻击可能性的地步。7 结论我们已经描述了系综，一个依靠用户社区在流行应用程序上检测或阻止异常的无监督异常检测和预防系统的设计。当地行为概要文件组合成一个全球配置文件，可以用来检测或防止代码注入或行为修改。系综的主机只需要在运行时定期总结贡献的配置文件数据(大约0.5 MB)。系综阐述了从可能有不同操作环境的主机合并配置文件的问题。基于对四个候选应用程序的57次测试的评估，我们发现全球配置文件的质量和由此产生的假阳性率，会随着社区大小增长到约300用户而极大地提高了，这些正好证明，使用社区来自动生成行为概要文件而不需要手工操作是一个可行的方法，以及由此产生的行为概要文件对实时异常检测和预防是有效的。Ensemble：Community-Based Anomaly Detection for Popular ApplicationsAbstract: A major challenge in securing end-user systems is the risk of popular applications being hijacked at run-time. Traditional measures do not prevent such threats because the code itself is unmodified and local anomaly detectors are difficult to tune for correct thresholds due to insufficient training data. Given that the target of attackers are often popular applications for communication and social networking, we propose Ensemble, a novel, automated approach based on a trusted community of users contributing system-call level local behavioral profiles of their applications to a global profile merging engine. The trust can be assumed in cases such as enterprise environments and can be further policed by reputation systems, e.g., by exploiting trust relationships inherently associated with social networks. The generated global profile can be used by all community users for local anomaly detection or prevention. Evaluation results based on a malware pool of 57 exploits demonstrate that Ensemble is an effective defense technique for communities of about 300 or more users as in enterprise environments.1 IntroductionEnd-user systems can be difficult to secure for a variety of reasons. They are typically unmanaged: users download software, browser bugs, etc. In this paper, we focus on defending against a class of attacks in which popular applications are hijacked at run-time. In the past, this has led to wide-spread attacks such as the Skype worm spread using Skype and buffer overflows in Outlook email clients to execute arbitrary code . Traditional measures, such as anti-virus scanners 5, do not prevent such threats because the application code itself is unmodified. Prior work indicates that system-call level profiling 23,33,37 may help detect such attacks early but a significant barrier is a lack of sufficient training data to ensure low false positive rates.In this paper, we present Ensemble, a novel unsupervised anomaly detection approach based on the idea of a trusted community of users contributing system-call level local profiles of an application to a common merging engine. The merging engine generates a global profile that captures the possible space of normal run-time behaviors of an application. The global profile can be used to detect or prevent anomalies in application behavior at each end-host in real time. The promise of this approach is that it helps overcome the problem of a lack of sufficient training data at each host and can be largely automated. The challenges are making such a system efficient, overcoming the differences in profiles due to factors such as variations in installation directories or hardware, and identifying the appropriate information to collect in profiles.The underlying hypothesis of Ensemble is that, as the number of local profiles increases,the aggregate global profile tends to converge, thus revealing the normal behavior of the target application. Most applications in our experiments were found to satisfy this property, though we also identified types of applications that would be exceptions. This paper makes the following contributions.Handling diversity in execution environments. Various factors impact community based profiling, e.g., the same application at different hosts may be installed in different directories, run with different amount of memory, and use different number of CPUs. All these can cause variations in the system call traces with their parameters. We determined the types of data to use for generating behavioral profiles to handle these variations, while keeping profiles compact and representative of the application.Analysis of the relationship between the community size and false positive rates. We first applied community-based anomaly detection to a community of 12 users using a normal, clean instant messaging application. The detailed system-call level data were sampled for 50 minutes during 5 hours with each local profile generated based on one minute of sampled data. We found that high false positive rates to be of significant concern, just as with single-host profiling using system calls. A testbed of virtual machines was subsequently used to study the impact of scaling up the system to a larger user community.We found that the techniques, in general, tend to become much more effective with larger community size. Significant reduction in false positive rates was observed after reaching approximately 300 users.Techniques to reduce data transfer by sharing summary data generated by profiling applications. We show that while each host collects detailed system-call level data 23,26,36 for local analysis, it only needs to send a modest amount of local profile data per application (approximately, 4-5 KB/sec) to a common server to create community profiles.A general interface. Our system provides a useful abstraction of a general interface for any target application to be protected. Multiple applications can subscribe to the Ensemble service. Ensemble is currently implemented in user space in Windows. We used Detour library by Microsoft Research to intercept system calls for target applications. For improved efficiency, as discussed in 4.2, Ensemble can be implemented as a service in the OS kernel. The rest of the paper is organized as follows: 2 overviews the related work; 3 describes the overall model of Ensemble; 4 details our implementation; and 5 evaluates the system experimentally. Finally, 6 discusses limitations before concluding in 7 end.2 Related WorkOur work improves on existing work in the area of anomaly detection by exploring the applicability of community-based profiling to generate detailed run-time behavior profiles of applications at the system call level. Below we highlight some of the related approaches in malware detection and containment.Anomaly Detection. One of the first studies on anomaly detection for applications was done by Forrest et al. 23,26,36. They executed an application multiple times with different in