用例——存档介绍CCE的创建是出于五个不同的上下文中使用案例企业中的安全配置管理。核心用例是内部配置管理生命周期,是一个企业内进行,下面描述的过程:四个部分系统设计,用于测试,部署和评估和修复。 其余四个CCE的用例可以被视为辐条来自核心周期都与之间的协调和沟通一些配置管理生命周期的一部分,一些利益相关者。这四个用例包括:系统设计、配置审计、合并审计报告和法规遵从性。 一个共同的主题在所有这些用例是使用CCE-IDs促进更快和更准确的相关配置信息不同,但实践密切相关。的每一个操作都有自己的流程,程序,专业领域。此外,每个实践的成员共享信息跨域边界与其他实践作为其工作的一部分。工作进行跨领域,有时一组通常共享“对象”将会出现,使不同的实践相互配合和协调他们的行动。这些对象是有时被称为“边界对象。”CCE-IDscan act as boundary objects in all five use cases. 边界对象的概念,介绍了由杰弗里Bowker和苏珊的明星内部排序问题:分类及其后果(技术)波士顿,麻省理工学院出版社,1999:
边界对象的一个很好的例子,大多数用户应该熟悉国际标准书号(ISBN)用于识别书。书中的世界有许多不同的实践社区,如图书出版商、零售商和图书馆,每个人都有自己的流程和过程跟踪和管理图书信息。我们可能期望两个图书出版商也有类似的做法,有相同的计费和库存系统,但我们不希望一个库存系统为图书出版将以任何方式使用一个图书馆。“书”的语义或示意图意义为这些实践社区是不同的。但尽管有这些不同的本地化的定义书,实践可以使用isbn协调他们的行动。cc是为了培养这种跨境协调行动的不同的安全配置管理实践上下文中。 在下面讨论的用例CCE的每个条目作为边界对象之间的两个不同但相关的社区和为他们提供了一个相互认可标识的配置问题。 配置管理生命周期这个用例涉及之间的工作沟通和协调四个(或更多)组参与组织中的配置管理包括系统设计,用于系统测试,系统的配置和部署,配置审计和补救。 场景公司计划在他们的网络上部署一套新的系统。为此,四个(或更多)组必须协调他们的行动在一个更广泛的配置管理生命周期。首先,系统设计者设计系统必须符合的要求,可能包括内部安全政策,外部定义的安全要求和操作要求。其次,系统测试人员将构建一个或多个系统根据设计测试系统的操作准备。第三,系统部署组将负责网络上部署测试系统。最后,评估和管理集团(可能被进一步分离)负责测试,以确保系统保持符合约定的配置设置,根据需要进行更改。 通常,捕获系统的配置标准内部创建的文档或电子表格。虽然是一个更加自动化的运动表达式的配置标准,这些自动化解决方案通常主要集中在一个单一的配置管理生命周期的一部分,因此无法进入组织生命周期的其他部分。这些新兴技术的例子包括政策管理产品,系统配置系统、网络管理功能(例如,活动目录组策略对象),和配置基准测试和审计工具。 问题为了配置管理生命周期中的不同群体来协调他们的行动,他们需要能够高效、准确地识别特定的配置控制。没有CCE-IDs,这些组织必须依靠上下文的“名字”呈现给他们不同的书面文件(例如,安全配置指南)和不同的安全工具(例如,组策略对象(gpo))。虽然这些名字往往是他们很少相同的相似,通常遇到两种类型的错误。首先,配置问题是一样的,但名字略有不同在不同的上下文中是不被认为是一样的。其次,问题是密切相关的,但不被认为是被不同的由于他们的名字的相似之处。 结果,撰写书面内部配置标准并不是有效的协调配置管理生命周期内的不同群体。映射错误在每一步的过程和分析的组织必须花费大量时间来解决差异。不同的组织需要一个机制,允许他们快速、准确地跨生命周期的每一步协作。 CCE如何帮助通过与CCE-IDs注释他们的内部定义的配置标准,组织参与的不同部分配置管理生命周期能够更好地相互沟通和协调他们的行动。在每一步的过程中,一个给定的组织可以使用CCE-IDs配置问题上找到更多的信息通过访问配置信息来源熟悉它们。这样,他们可以更快速和准确的配置标准映射到自己的局部环境和工具集。 在这个场景中,CCE-IDs作为边界对象的边界不同实践中的配置管理生命周期。虽然每个实践(设计、测试、部署、审计和补救)处理配置控制的概念,准确命名或关节的控制通常不同于练习,再练习。CCE-IDs共享对象,可以很容易地映射到每个实践。 指导文档编写和系统设计这个用例涉及跨境协调和沟通之间发生配置指南作者和系统设计师。 场景配置指南作者一直负责为特定平台编写指导文档。产生的可交付成果将会是一个人类可读的散文文档提供作为静态文档(例如,PDF,微软字处理软件)或作为一个动态分配的文档(例如,HTML、XML、可扩展的配置清单描述格式(XCCDF))。作者可能为主要供应商组织工作,销售平台(例如,苹果,微软,红色帽子,太阳)或一个组织,负责指导大型人群(例如,网络安全中心(CIS),美国国防信息系统局(DISA),国家标准与技术研究院(NIST),国家安全局(NSA))。 同时,责成系统设计师设计一个新的或更新现有配置标准(模板)系统部署在他们的组织。设计师需要考虑的安全影响每个配置控制确保系统符合公司的安全政策。此外,她需要文档是否和如何设计符合行业最佳实践。为了实现这一点,她就会读安全配置指南发布平台供应商和相关第三方。她还将审查信息在特定的配置设置发现在网站维护的供应商和论坛。最终产品,系统设计师将产生一个文档,描述了应用的配置设置。她会,在大多数情况下,也需要文档的引用相关的最佳实践文档为了证明她的决定。 问题安全配置指南的主要功能之一是他们依赖散文作为主要的通讯手段。这让这些人类可读的文档。它还允许作者提供一般指导,应该是人类为了解释适用于一个特定的技术实现或在一个特定的操作设置。例如,广义指导“使用强密码”是有效的指导,但必须由人类为了解释被应用在一个特定的上下文因为有密码强度的许多方面。另一方面,人类的力量的散文,允许它用于描述模棱两可的概念还允许不同的读者以不同的方式解释指导。并不是所有技术的读者将识别相同的密码属性列表当解释“使用强密码”。 越来越多的安全指南的作者开始增加它们的人类散文与特定技术项目列举相应的技术控制的列表。虽然这有助于消除歧义的部分人类的散文,这不是一个完整的解决方案有两个原因。首先,缺乏CCE-IDs,配置指南,系统设计师咨询都指个人配置设置自己的术语,这意味着它同样的问题普遍认同不同的名称在不同的文档。二、密切相关,由于频率相关的功能集,它不是经常会有显著相关但不同的配置控制的“命名”几乎相同的方式。,常见的错误是发生在系统设计师试图调和指导两个不同来源什么她认为是相同的配置控制(由于他们的类似名称)时,事实上,他们是不同的控制。第三,由于许多配置控件本身就是建立在其他子系统和系统调用,它并不少见不同的安全指南注释他们的散文试图列举系统控制在不同的抽象级别或粒度,进一步混淆了系统设计师当她试图调和这两个指导文档。 缺乏一个常见的方式来确定配置控制意味着系统设计者必须搜索文档手工或使用容易出错的关键词搜索,如果她有一个电子文档的副本。因此,她必须花很大一部分时间试图找到适用的部分在指导文档。相似的相似但不同的控件的命名实践意味着有时她必须花额外的分析时间来确定从两个不同的文档部分,事实上,指的是相同的控制。缺乏共同的标识符配置控制也意味着她必须依靠容易出错的关键词搜索时咨询在线资源维护的供应商或在搜索网络信息。结果是更长的分析时间在她的研究和更多的错误当试图集成来自多个源的信息。 CCE如何帮助书面安全指南与CCE-IDs注释允许系统设计师快速而准确地识别文档的哪些部分与配置控制她。使用CCE-IDs增强人类的散文是更有可能的枚举技术控制,出现在两个不同的文档更容易被表达在同一层次的抽象(抽象级别相应的CCE-IDs),这使得它更有可能在概念上类似的指导文件。此外,多种安全指南中使用CCE-IDs意味着系统设计者可以快速、准确地将信息从导游尽管指南的格式不同,可能引用同一个问题稍微不同的专有名称。使用CCE-IDs让她快速识别和忽略那些不相关的部分控制她感兴趣,尽管它类似的“名字”。This reduces her analysis time and makes it more likely that she will avoid mistakes made from attempting to incorporate erroneous information. 使用CCE-IDs在线支持供应商所提供的设施和其他在线资源包括论坛允许系统设计师快速、准确地找到更多相关的信息在互联网上。这种类型的增加可以目睹今天使用的可寻性CVE标识符。 关于使用CCE-IDs边界对象在这个场景中,我们注意到系统设计和安全指导创作是不同但相关的实践。虽然是常见的安全指南的作者在系统设计和管理经验,创建向导的过程不同于设计系统的过程。有效,安全指南的作者和系统设计师需要合作,虽然间接通过书面安全指南的出版和阅读。在一个特定的配置控制会有不同的表达方式指导系统定义相比,他们是密切相关的。CCE-ID足够塑料是有用的在这两个领域,允许配置的工作指导和相关系统设计是有效的。 应该注意的是,每一个的分配CCE条目平台组cc的基础上促进夹杂物安全指南和在线帮助系统。通常,这些资源是编译和创建的组专家在每个平台组的基础上。每个平台的基础上通过发行cc, cc更符合现有的实践领域内的安全指导。 配置工具配置以下用例关注创造者之间的沟通和协调配置管理工具和最终用户的工具。这个用例可以被视为一个单独的组件配置管理生命周期的上面描述的用例。然而,这个用例强调外部跨境协调供应商和客户之间的组织,而生命周期配置管理强调组织内部跨边界组织之间的协调。 场景供应商生产工具针对配置管理生命周期的一部分。一些最常用的产品包括配置管理工具,实施或更改配置设置在端系统(例如,MS活动目录组策略对象),和配置审计工具,用于测试端系统的配置状态。供应商创建产品,他们的产品努力代表配置问题的方式将是最有用的和可理解的顾客,他们的“客户”不仅包括产品的最终用户也组织内部客户的利益相关者参与其他方面的配置管理生命周期,必须协调和沟通产品和产品的最终用户。厂商面临的挑战是如何呈现的名称或标识符配置控制或配置检查,允许最终用户理解的意义一个控制或找到一组特定控制的控件。 IT管理员负责部署和操作使用配置管理工具一直肩负着的责任调优工具来实现配置管理生命周期的一个步骤。作为一个生命周期的一部分,管理员需要输入一些组配置控制。这可能是组控制部署或强制使用配置管理工具或一组控制审计评估使用配置的工具。成功完成这项任务管理员必须non-ambiguously输入的一组控件映射到特定的检查或功能在工具。在大多数情况下,管理员也会被要求写文档之间的映射配置文件内和特定的检查工具。 问题缺乏CCE-IDs,工具供应商必须在其产品名称个人支票或控制,是基于自己的专有的命名约定。这些专有名称通常是相关但不同于其他名称相同的配置控制中使用的其他工具或文档。事实上,可以选择故意区分自己的专有的命名方案从其他供应商所使用的命名方案和安全指导作者关于侵犯版权,以避免任何可能的挑战。类似于配置指南的作者所面对的挑战,供应商也必须选择合适的抽象级别粒度的控制或检查的单位信息的工具是最好的对齐不仅与最终用户的即时需求,而且这样的工具集与其他工具、功能,和利益相关者参与配置管理的生命周期在用户的组织。 缺乏CCE-IDs所需配置的列表控件形式的输入过程和配置管理工具,用户必须依赖于详细的人类分析成功的配置控制列表映射到该工具。为此,用户将需要依靠她的分析的详细文档提供的供应商控制。映射错误产生的这一过程类似于映射系统设计者面临的错误。控制工具相匹配的控制输入列表可能不被认为是相同的。相反,管理员可能将一个输入控件映射到一个控制的工具,事实上,控制是不同的。更糟的是,如果控制的工具和控制输入列表(和其他组织的配置管理实践)在不同的抽象级别,这将是几乎不可能输入列表映射到该工具与高度的一对一的对应关系。 CCE如何帮助当输入列表的控件(由另一个组织的内部配置管理实践的一部分)和控制供应商的产品都是正确与CCE-IDs注释,管理员可以快速、准确地互相关联的数据集,从而降低部署成本,最小化错误,否则可以传播到整个组织的配置管理生命周期。更重要的是,如果两个配置管理控制的工具和组织的方式都是在同一层次的抽象,然后可以集成到工具的结果组织的生命周期配置最大数量的一对一的对应关系。 值得注意的是在这一点上,大多数的配置管理和评估产品的控制管理在“每个平台”的基础上,与CCE的平台组。从不同的平台组治疗类似的控件是截然不同的,CCE-IDs更紧密与现有的配置管理工具和内部实践在组织生产内部配置标准。 在这个场景中,CCE-IDs充当跨越边界边界对象之间存在的配置管理工具和客户的组织。成功与他们的个人要求,供应商和客户的组织必须建立并维持一个持久的共享实践对认识和管理配置控制。通过提供一个可共享的组标识符和阐明CCE定义共享的抽象层次,CCE帮助这些不同的团体协调他们的行为。 审计结果集成工具像之前的用例,该用例可以被视为一个配置管理生命周期的一部分。然而,这个用例通常只是与大型企业的组织需要集成来自多个配置审计工具部署的结果不同部位的组织。这个用例可能正确地视为涉及多个配置审计工具供应商之间的协调和沟通,组织试图集成代理的结果。 场景在一个组织内部开发人员负责巩固系统审计报告来自几个不同来源为了创建和支持一个完整的报告功能。数据源他必须手动将从内部系统进行审计,手动进行外部第三方审核,结果从几个商业审计工具部署的企业的多个部分。预期用途的综合报告功能可能包括IT运作态势感知,决策支持管理,或遵从性报告。 全面完成这项任务,开发人员必须做两件事。首先,他必须创建一个表示的配置控制能够捕获的最大数量配置控制各种评估测试的功能。第二,他必须每个不同的评估功能映射到这个集中的表现。 问题缺乏CCE-IDs,困难在于每个数据源的结果使用专有术语表达的结果。整合各种审计报告的手动过程非常耗时且容易出错以同样的方式,其他映射练习。比较必须基于原油搜索关键词搜索等机制,必须经由劳动密集型个别项目的分析。常见的错误模式是相似的。项目从不同的工具,检查相同的配置控制不确定是相同的,项目是相互匹配时,事实上,他们检查不同的问题。更重要的是,如果不同的工具,手工审计技术,和内部配置管理实践都使用不同的抽象级别代表配置信息,在一些实例中,一一对应项目之间是不可能实现的。因此,综合报告是由于广泛的劳动力成本,代价高昂的错误,和模棱两可的结果的抽象级别不匹配的结果。 CCE如何帮助如果所有的配置工具和功能与CCE-IDs标记,开发人员可以快速而准确地地图。更深入,如果开发人员构建他的内部的统一表示基于CCE的配置问题,那么它更有可能的是,他的报告能力和工具都将代表配置信息管理和大致相同的抽象级别,从而最大化数量的实例数据与一个一一对应。 应该注意的是,大多数配置评估检查商业产品在每个平台的基础上创建和分发与CCE密切相对应的平台组。通过分配不同的CCE-IDs类似问题出现在不同版本的平台,CCE-IDs在与编码的通用实践的亲密盟友审计工具。这样可以确保CCE-IDs之间的一对一对应的最大数量和检查评估产品。 (注:这是常见的配置审计功能和工具来测试目前没有CCE-IDs配置问题。特别是,它是常见的审计工具,包含测试产生的系统对象列表,以便管理员可以检查列表和列表是否做出决定是适当的。例如,一个常见的检查这种类型的是产生一个列表的所有本地用户管理权限的系统。用户管理权限的列表之前必须手动审查审计发现可以创建。本文的写作时间,CCE-IDs并没有发布这些类型的问题,尽管他们可能在将来的某个时候。联系cce@mitre.org为更多的信息。) 在这个场景中,CCE-IDs作为边界对象之间存在的界限不同配置评估工具和能力。而特定工具供应商可能会或可能不会打算相互协调和沟通,组织的数据集成需求要求输出被集成的工具。在某种意义上,组织的开发人员负责的数据集成作为一个代理供应商工具的相互沟通,具体工作由每个专用工具配合其他工具的工作。通过提供一个可共享的组标识符和阐明CCE定义共享的抽象层次,CCE帮助专利实践中不同的工具相互协调。 法规遵从性这个用例涉及跨境从业者之间的协调和沟通,发生在配置管理生命周期与法规遵从性和利益相关者的利益。这些利益相关者可能是组织内部的或外部的组织,但在这两种情况下,他们不直接参与直接配置管理生命周期。相反,他们感兴趣的是如何组织的配置管理实践支持某些法规遵从性目标。 这些监管目标可能是动力的需要遵守适用的法律和协议,如《萨班斯-奥克斯利法案》,HIPAA, FISMA,巴塞尔协议II,行业标准如签证/ PCI合作,甚至他们自己的内部政策。然而,它控制并不是直接映射到法律或法规要求。相反,是从安全的角度判断标准的遵循或审计框架。COBIT框架的例子包括ISO 17799, NIST sp800-53, ITIL,国防部8500.2。 场景一个组织的成员配置管理团队一直负责记录他们的内部如何配置一个特定平台符合标准或支持一组特定的法规遵从性需求。她是负责提供的可交付文档映射配置成一组标准的需求,这通常是来自一个框架文档。同时,审计人员是负责审查组织的配置标准,以确定其符合或支持监管目标的列表。 配置管理团队之间的协作和审计人员将在一个或两种形式。首先,审计人员可能会选择直接检查工件和文件从配置管理实践,代表或文档配置标准是如何定义和部署。这可能包括书面配置标准产生的系统设计师,与其余的配置和共享的管理团队。这可能还包括检查数据存储在配置部署工具使用等活动目录组策略对象。或者这可能包括审查配置审计工具的结果。 第二种方法,配置管理团队和审计师可能沟通是通过一份报告,将特定的配置控件映射到监管要求的列表。这种映射有时被称为一个需求跟踪矩阵(RTM)。因为框架文档写入地址不同的观点通常是平台独立的,通常RTMs包含一对多和多对多关系。 问题没有CCE-IDs,配置管理团队必须展示他们的平台使用他们自己的内部配置标准命名约定或从非标准化的命名约定借贷来的许多工具集。虽然其内部命名的选择可能有一定程度的熟悉这些人在内部配置管理生命周期工作,审计人员不熟悉。所以没有CCE-IDs审计人员和配置管理团队必须努力使每个配置项理解审计人员。为此,他们将需要完全依赖配置团队内部的文档来帮助阐明每一个配置项,然后地图列表的审计师的预期控制。与其他映射的练习,这个过程是劳动密集型且容易出错。 越深,并不少见审计师考虑配置控制在不同的抽象级别在不同的上下文中。非常不寻常的审计员和实践者在配置管理生命周期思考和讨论配置在不同的抽象级别控制。 CCE如何帮助当组织注释与CCE-IDs自己内部的配置标准,审计人员就容易评估合规。CCE-IDs,它可能对审计人员和配置管理团队快速和准确地比较组织与其他行业最佳实践,RTMs RTM。即通过标准化与CCE-IDs配置控件的标识,就可以表达标准化预计RTMs为特定平台。同时,CCE-IDs审计人员可以快速、准确地评估配置标准是如何实现配置管理生命周期的所有方面。 在这个场景中,CCE-IDs作为审计人员和参与者之间的边界对象配置管理生命周期。特别是,我们注意到,通过建立一个标准的抽象级别,从业人员在配置管理实践中比较普遍和编纂在CCE的抽象级别,CCE-IDs帮助澄清否则可变的配置控制审计师的概念,它允许审计人员更好地定位自己的表情控制使用的配置管理实践者。我们必须强调合作的持续实践审计人员和配置经理足够耐用,审计师最终有可能理解控制,尽管自己的倾向认为控制在不同的抽象级别。然而,CCE-IDs作为边界对象帮助促进审计和配置管理实践的共同取向。 |
