语言的结构
官方的椭圆形语言包括三个不同的类别:系统特征,定义,和结果。每个类别都包含一个核心模式和组件模式。
椭圆的定义模式
椭圆定义模式用于定义XML框架编写:(1)椭圆脆弱性定义通过定义的条件必须存在电脑上特定的漏洞存在,(2)椭圆形补丁定义通过在计算机上定义的条件,确定一个特定的补丁是否适合于一个系统,(3)椭圆形库存定义通过在计算机上定义的条件,确定是否一个特定的软件是安装在系统,和(4)椭圆形合规定义通过在计算机上定义的条件,确定符合一个特定的政策或配置语句。工具和服务,利用定义模式列出创作工具,定义评估者,定义存储库在采用椭圆形部分。
椭圆的定义模式,随着椭圆系统特征模式和椭圆形的结果,不是对自己个人模式但都由一个“核心”模式和“组件”模式的集合。椭圆形的核心模式提供了总体结构的定义,以及一个表达元数据是独立的测试(例如,CVE标识符,影响平台,和描述),而组件模式定义特定的椭圆形语言使用的测试来找出漏洞,配置和安全问题在一个操作系统(OS)或应用程序。
椭圆形的系统特征模式
椭圆形的系统特征模式定义了一个标准的XML格式表示的系统配置信息。这个配置信息包括操作系统参数,安装软件应用程序设置,和其他安全相关的配置值。该模式的目的是提供一个椭圆形的“数据库”的系统特征定义可以为了分析一个系统漏洞相比,配置问题,和补丁。从本质上说,该模式定义了一个标准的系统特征交换格式,可以被纳入各种工具,如列系统特征生产商在采用椭圆形部分。
与椭圆定义模式,椭圆形的系统特征模式由一个核心模式和组件模式的集合。核心的功能模式是类似的核心模式在椭圆的定义模式。组件模式定义的格式和内容的配置参数的收集,和大致对应于椭圆定义中指定的测试模式。
椭圆形的结果模式
椭圆形结果模式定义了一个标准的XML格式来存储结果的评价系统。结果数据包含系统的当前状态的配置相比对一组椭圆的定义。椭圆形结果模式允许应用程序使用这些数据,解释它,并采取必要的行动来减轻漏洞和配置问题(例如,安装补丁,改变系统配置设置,和/或采取外部的预防措施来限制访问受影响的系统)。这个模式还定义了一个标准的漏洞和错误配置交换格式,可以被纳入各种工具,如列结果消费者在采用椭圆形部分。
再次,椭圆形的结果模式由一个核心模式和组件模式的集合。组件模式的主要区别在椭圆形结果模式与椭圆的定义,是在椭圆形模式每个测试结果包含的信息用于确定是否存在漏洞或错误配置除了特定的系统数据分析得出最终结果。
组件模式
椭圆形的组件模式由一组相关的测试在某种程度上他们描述的软件。跨多个不同的组件测试相同的模式,因此代表了一类更一般的测试,在更高级别的组件模式组合在一起。例如,有不同的组件模式为Linux和Solaris,但这些都有相同的结构文件测试。由于这种相似性,UNIX文件测试坐落在一个概念上高级模式。的条件确定的水平测试应该在本文档后面放置了。
这个层次结构的模式是纯粹的概念,然而,由于没有实际的链接。例如,包测试在Solaris模式不继承方面从UNIX包测试模式。请注意,所有的测试报告做一组标准的继承属性和元素的核心模式。概念层次结构是椭圆形的语言发展的副产品。而需要一个真正的层次结构内的椭圆形语言尚未出现,它已经认识到这种需求可能在将来的某个时候进化。
概念的椭圆形的语言- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -椭圆定义模式| | - - >核心模式| | - - >独立模式(family_test, variable_test, xmlfilecontent_test等等)。| | - - > UNIX模式(file_test, process_test uname_test,等等)| | | | - - > Solaris模式| | - - > hp - ux模式| | - - > MacOS模式| | - - > Linux模式(dpkg_test、rpminfo_test等)| | - - >窗口模式(file_test、wmi_test等)| | - - > Apache模式
椭圆的定义可以把来自多个不同的测试模式。例如,一个单独的定义可能使用的family_test独立模式(注意,独立模式定义了一组测试不相关的特定的软件),从UNIX process_test模式,从Linux rpminfo_test模式。这些定义的验证与每个测试相关的名称空间。
分离的多个组件模式的优点是测试描述不同类型的软件(例如,测试处理Red Hat和Solaris),同时相关的测试分组在一起(例如,测试处理常见UNIX)。一个软件供应商发现需要创建一个椭圆形语言之外为了支持他们的软件可以设置新的测试组织成一个新的组件模式。的新组件模式可以添加到椭圆形语言允许软件供应商集中精力提炼自己的模式,而不是试图修改现有模式(s)包含测试并不适用于他们的产品。
这种结构的另一个优点是,新软件支持的椭圆形,之前写的内容使用高级组件模式不需要修改。例如,在早期版本的椭圆形,模式是由操作系统和分解没有更高级的UNIX模式的概念,因此,尽管file_test相同的Red Hat, Solaris和Debian平台的实例测试必须包含在每个模式。在某些情况下,这故障引起多个相同的椭圆定义写到占每个平台。进一步复合问题,添加一个新的基于unix平台,如hp - ux,会导致创建一个新的重复测试。在当前方法,可以编写一个定义包含所有unix平台,即使是那些被添加后,创建了定义。
最后,将椭圆语言分成组件模式允许工具目标选择的一组应用程序或操作系统,在这一过程中,减少过程开销和执行时间。在4.1以前的版本的椭圆形工具被迫管理一个大型模式的平台选择。这有时意味着模式包括测试工具无关,和增加了处理开销。
这种方法的潜在陷阱是一个模式结构笨重庞大,用户很难导航。因此,必须非常小心,以确保相当大的思想放入规定的结构模式,遵循规则,规则是有据可查的。通过为用户提供一个逻辑,充分记录格式,他们应该能够迅速定位模式中的任何测试。
放置一个新的测试
创建一个新的测试时,有几个问题需要解答,为了确定其语言层次结构中的位置。这个测试满足检查一个特定的软件组件的需要就其本身而言,还是有一组相关的新测试的函数来描述组件的问题吗?这个测试是针对特定的应用程序,或者解决一个更一般的配置问题吗?
第一个问题的答案将决定测试应该被纳入现有的组件模式,或与其他新的测试分组形成一个新组件模式。例如,一个新的测试,检查特定的配置Windows服务将被纳入现有的模式。一组5个新的测试,检查Oracle数据库的配置将形成一个独立的甲骨文的基础模式。
第二个问题的答案决定了哪些测试将被放置在组件模式。测试,可以使用更广泛的跨一组模式是放置在一个更高级别的组件模式,而测试,更专注于一个特定的方面系统的配置将被放置在概念层次结构。
与这种类型的任何决定,必定有争论创建一个新模式的优点,并测试是否真的一般。在这种情况下,椭圆社区的成员被鼓励提出自己的观点,与椭圆板作为最后的仲裁者。这次讨论的目的是将被纳入的文档测试,以及在未来提供先例来改进过程。
受影响的家庭关系
在4.1以前的版本中椭圆形语言的定义被分组受灾家庭的价值。为受灾家庭的列表值,因此可能的分组,与不同的组件模式。每个有效影响家庭模式与现有的组件。这种关系已经从4.1和更高版本删除。例如,它不会有意义有影响家庭的Apache。注意,受影响的家庭是为了描述家庭的OSs椭圆定义适用于。影响家庭的目的仍然相同但值现在宣布独立的组件模式。
页面最后更新:2012年1月11日,
