系统安全工程能力 成熟模型 (SSE-CMM) 简介

1. 　系统安全工程能力成熟模型(SSE-CMM)简介 三零卫士信息安全事务所

2. SSE-CMM概述 • 信息系统安全工程 • SSE-CMM模型 • SSE-CMM过程能力级别 • SSE-CMM过程域

3. SSE-CMM的背景 • 1993年04月 美国NSA赞助将CMM模型应用 到安全工程的研究 • 1995年01月 60多个相关组织确认此项研究 的必要性，并参加研究工作 • 1996年10月 公布SSE-CMM 1.0版 • 1997年04月 公布SSE-CMM评估方法 1.0版 • 1998年10月 公布SSE-CMM 2.0 Beta版和评 估方法2.0版的讨论稿 • 1999年05月 SSE-CMM评估方法2.0版

4. SSE-CMM的范围 • 涉及可信产品或可信系统的整个生存期的安全工程活动，包括概念定义、需求分析、设计、开发、集成、安装、运行、维护和终止。 • 可用于产品开发商、安全系统开发商及集成商、提供安全服务和安全工程的组织机构。

5. SSE-CMM的益处 • 工程组织：可重复、可预测的过程和实施减少返工；获得工程能力的认可；可度量的能力和改进。 • 用户：可重用的鉴定方法；减少选择不合格的投标者的风险；基于标准评估减少争议；建立可预测和可重复的可信度 • 评估机构：与系统或产品无关的可重用的评估过程；基于能力的可信性，减少安全评估的工作量

6. 安全工程的目标 • 理解企业的安全风险。 • 根据安全风险建立平衡的安全需求。 • 将安全需求转换成安全指南，并将安全指南集成到项目实施、系统配置和运行中。 • 在正确有效的安全机制下建立信心和保证。 • 判断系统残余的安全弱点是否可以容忍。 • 对系统安全的可信性建立共同理解。

7. 安全工程的要求 • 连续性 可重用的知识。 • 可重复性 确保项目可成功地重复实 施的方法 。 • 有效性 帮助开发者和评估者有效 工作的方法。 • 确证性 落实安全需求的信心。

8. 过程和安全工程过程 • 过程是为一个目的而执行的一系列活动。这些活动将输入工作产品转换为输出工作产品，提供给其他活动。 • 安全工程包括 • 识别风险：评估威胁、评估脆弱性、评估影响。 • 实施安全工程：确定安全需求、提供安全输入、管理安全控制、监视安全状态、协调。 • 确保信任程度：核实和确认安全性、建立可信性论据

9. 过程域 构成过程域，当全部实现后可满足过程域的要求 基本实施 （Base Practices） 一组相关的基本实施，完成后可达到过程域的目的 过程域 （Process Area） 过程类 （Process Category） 一组过程域的集合，属于同一领域的活动

10. 过程能力 能力级别 （Capability Level） 一般实施 （Generic Practices） 通用特征 （Common Features） 反映执行和改善任何过程的程度 一组一般实施的集合，执行过程的一个方面 一组通用特征的集合，反映执行过程的能力

11. SSE-CMM结构 过程域 Domain Aspect Base Practices Process Areas Process Category 5 4 过程能力Capability Aspect 3 Generic Practices Common features Capability Level 2 1 0 PA01 PA02 PA03 ...

12. 过程能力级别 持续发展要求健全的管理实施，已定义的过程、可测量的对象作为基础 持续改进级：从各级中获得并保持平衡 知道是什么后才能测量，测量对象正确时测量才由意义 量化控制级：与组织的商务目标联系的量化和测量 以项目中所掌握的东西定义组织级别的过程 良好定义级：在组织级别上规范化的剪裁过程 定义组织级别过程前澄清项目过程 计划跟踪级：在项目级别上定义、计划、执行过程 先实施才能管理 非正式执行级：执行包含基本实施的过程

13. 计划跟踪级 • CF2.1，计划执行 • 分配资源、责任，过程文档化，提供工具， 保证培训， 计划过程 • CF2.2，规范执行 • 使用计划、标准、程序，进行配置管理 • CF2.3，确认执行 • 验证过程一致性， 审计工作产品 • CF2.4，跟踪执行 • 使用测量跟踪，采取修正措施

14. 良好定义级 • CF3.1，定义标准过程 • 过程标准化，剪裁标准过程 • CF3.2，执行定义的标准过程 • 使用充分定义的过程，执行缺陷复查，使用充分定义的数据 • CF3.3，协调安全实施 • 执行组内协调，执行组间协调，执行外部协调

15. 量化控制级 • CF4.1，建立可测的质量目标 • 建立质量目标 • CF4.2，客观地管理执行 • 确定过程能力，使用过程能力

16. 持续改进级 • 改进组织能力 • 建立过程有效性目标，持续改进标准过程 • 改进过程有效性 • 执行因果分析，消除缺陷的原因，持续改进已定义的过程

17. 过程域类 • 组织过程域类 • 项目过程域类 • 安全工程过程域类

18. 项目过程域类 • PA08 保证质量 • PA09 管理配置 • PA10 管理项目风险 • PA11 监控技术投入 • PA12 计划技术投入

19. 组织过程域类 • PA13 定义组织的系统工程过程 • PA14 改善组织的系统工程过程 • PA15 管理产品系列的发展 • PA16 管理系统工程的支持环境 • PA17 提供不断发展的知识和能力 • PA18 协调供应商

20. PA01 管理安全控制 PA02 评估影响 PA03 评估安全风险 PA04 评估威胁 PA05 确定弱点 PA06 建立保证证据 PA07 协调安全 PA08 监察安全状况 PA09 提供安全输入 PA10 确定安全需求 PA11 核实和确认安全性 安全工程过程域类

21. 安全工程过程域类 产品或服务 工程过程 风险信息 保证增强 风险过程 保证过程

22. 风险过程 威胁信息 评估威胁 风险信息 评估安全风险 弱点信息 评估弱点 影响信息 评估影响

23. 安全工程过程 风险信息 检查安全状况 确定安全需求 配置信息 要求、政策等 协调安全 方案、导引等 提供安全输入 管理安全控制

24. 保证过程 保证 核实和确认安全性 保证增强 建立保证证据 保证 其他过程域

25. PA01管理安全控制 • 目的：保证集成到系统设计中的预期的系统安全性确实由最终系统在运行状态下达到。 • 目标：安全控制已完全控制和使用。 • 基本实施： • BP01.01 建立安全控制的职责和责任并通知到每个人。 • BP01.02 管理系统 安全控制 的配置。 • BP01.03 管理所有使用者和管理员的安全意识、培训和教育。 • BP01.04 管理安全服务及控制机制的定期维护和管理。

26. PA02 评估影响 • 目的：识别相关影响，并评估其可能性。 • 目标：对系统风险的影响进行标识和刻画。 • 基本实施： • BP02.01 识别、分析、划分关键性操作、商务、任务能力。 • BP02.02 识别和刻画支持系统关键性操作能力或安全目标的资产。 • BP02.03 选择评估影响的尺度。 • BP02.04 标识被选择尺度与转化因素间的关系。 • BP02.05 标识和特征和影响。 • BP02.06 监视所有影响的变化。

27. PA03 评估安全风险 • 目的：识别环境中依赖于系统的风险。 • 目标：理解给定环境中的安全风险，按已定义的方法论为安全风险划分优先级。 • 基本实施： • BP03.01 选择用于分析、评估和比较给定环境下的系统安全风险所依据的方法、技术和准则。 • BP03.02 识别威胁/弱点/影响的组合。 • BP03.03 评估与上述组合相关的风险。 • BP03.04 评估上述组合及风险的总体不确定性。 • BP03.05 排列风险的优先级。 • BP03.06 监视风险的系列和特征的变化。

28. PA04 评估威胁 • 目的：识别安全威胁及其性质和特征。 • 目标：标识和刻画系统安全的威胁。 • 基本实施： • BP04.01 识别由自然因素引起的威胁。 • BP04.02 识别由人为因素引起的，偶然或故意的威胁。 • BP04.03 识别在特定环境下适当的度量单元和使用范围。 • BP04.04 评估人为因素的威胁方的能力和动机。 • BP04.05 评估威胁事件出现的可能性。 • BP04.06 监视威胁系列和特征的变化。

29. PA05 确定弱点 • 目的：识别和刻画系统的安全弱点。 • 目标：理解特定环境下的系统弱点。 • 基本实施： • BP05.01 选择对特定环境下的系统弱点进行识别和刻画的方法、技术、标准。 • BP05.02识别系统弱点 • BP05.03 收集与弱点相关的数据。 • BP05.04 评估系统弱点，并综合分析并系统弱点及特定弱点的组合。 • BP05.05 监视弱点及其特征的变化。

30. PA06 建立保证证据 • 目的：向客户澄清安全需求已满足。 • 目标：工作产品和过程向客户澄清其安全需求已满足。 • 基本实施： • BP06.01 识别安全保证目标。 • BP06.02 为所有保证目标定义安全保证策略。 • BP06.03 识别并控制安全保证证据。 • BP06.04 分析安全 保证证据。 • BP06.05 提供满足客户安全需求的安全保证论据。

31. PA07 协调安全 • 目的：保证所有部门有参与安全工程的意识。 • 目标：项目组所有成员具有参与安全工程的意识，充分发挥作用。有关安全的决定和建议是相互沟通和协调一致的。 • 基本实施： • BP07.01 定义安全工作的协调目标和相互关系。 • BP07.02 识别安全工程的机制。 • BP07.03 促进安全工程的一致性。 • BP07.04 用识别出的机制去协调有关安全的决定和建议。

32. PA08 监察安全状况 • 目的：保证识别并报告所有安全违规、对安全违规的尝试、导致安全违规的错误。 • 目标：探测和跟踪内部和外部的相关安全事件。根据策略响应突发事件。根据安全目标识别并处理安全状况的改变。 • 基本实施： • BP08.01 分析事件记录，确定其原因、如何发生、可能发生的事件。 • BP08.02 监视威胁、弱点、影响、风险和环境的变化。 • BP08.03 识别与安全相关的 事件。 • BP08.04 监视安全措施实施和功能的成效。 • BP08.05 监察系统的安全状况以识别必要的变更。 • BP08.06 管理与安全相关的突发事件的响应。 • BP08.07 保证有关安全监视的设备得到适当保护。

33. PA09 提供安全输入 • 目的：为系统的规划者、设计者、实施者、用户提供所需安全信息。 • 目标：所有有安全意义的系统问题都受到检查，并按安全目标的要求解决。所有项目组成员都理解安全问题，各司其职。解决方案反映安全输入。 • 基本实施： • BP09.01 与设计者、开发者、用户工作，确保相关人员共同理解安全输入。 • BP09.02 为正式的工程选择确定限制和考虑。 • BP09.03 标识与安全相关的工程问题的替代方案。 • BP09.04 利用安全限制和考虑比较工程方案，划分优先级。 • BP09.05 向其他工程组提供安全相关指南。 • BP09.06 向操作系统的用户和管理员提供安全相关的指南。

34. PA10 确定安全需求 • 目的：明确为系统识别出与安全相关的要求。 • 目标：所有部门，包括客户间达成安全要求的共识。 • 基本实施： • BP10.01 理解客户的安全要求。 • BP10.02 识别特定系统法律、策略、标准、外部影响和约束。 • BP10.03 识别系统用途，以此决定安全的关联性。 • BP10.04 获得系统操作的高层安全视图。 • BP10.05 获得定义系统安全的高层目标。 • BP10.06 一致地陈述将实施的安全保护措施。 • BP10.07 征得客户满足安全需求的认可。

35. PA11 核实和确认安全性 • 目的：确保安全问题的解决得到核实和确认。 • 目标：解决方案满足安全需求，满足客户操作安全要求。 • 基本实施： • BP11.01 确定待核实和确认的解决方案。 • BP11.02 定义核实和确认解决方案的方法和严格等级。 • BP11.03 核实解决方案满足高层抽象的要求。 • BP11.04 通过展示解决方案满足高层抽象的要求，并最终满足客户的安全要求，证实解决方案。 • BP11.05 为其他工程组收集核实和确认的结果。

36. 过程改善/CMM参考资料 • Deming, W.E., Out of the Crisis, Cambridge MA: Massachusetts Institute of Technology Center for Advanced Engineering Study, 1986. • Humphrey, W.S., “Characterizing the Software Process: A Maturity Framework,” IEEE Software, Vol. 5, No. 2, Mar 1988, pp. 73-79. • Office of the Under Secretary of Defense for Acquisition, Washington, D.C., Report of the Defense Science Board Task Force on Military Software, Sept 1987. • Paulk, M.C.; Curtis, B.; Chrissis, M.B.; Weber, C.V., Capability Maturity Model for Software, Version1.1, Software Engineering Institute, CMU/SEI-93-TR-24, Feb 1993. • Paulk, M.C.; Weber, C.V.; Garcia, S.; Chrissis, M.B.; Bush, M., Key Practices of theCapability Maturity Model, Version1.1, Software Engineering Institute, CMU/SEI-93-TR-25, Feb 1993. • Software Engineering Institute, “Benefits of CMM-Based Software Process Improvement: Initial Results,” Software Engineering Institute, SEI-94-TR-013, 1994.

37. SSE-CMM参考资料 • Ferraiolo, K.; Thompson, V., “Let’s Just Be Mature About Security,” Crosstalk, The Journal of Defense Software Engineering, September 1997. • Ferraiolo, K.; Sachs, J., “Determining Assurance Levels by Security Engineering Process Maturity,” Proceedings of the Fifth Annual Canadian Computer Security Symposium, May 1993. • Ferraiolo, K.; Williams, J.; Landoll, D., “A Capability Maturity Model for Security Engineering,” Proceedings of the Sixth Annual Canadian Computer Security Symposium, May 1994. • Ferraiolo, K.; Sachs, J., “Distinguishing Security Engineering Process Areas by Maturity Levels,” Proceedings of the Eighth Annual Canadian Computer Security Symposium, May 1996. • Gallagher, L., Thompson, V., “An Update on the Security Engineering Capability Maturity Model Project,” Proceedings of the Seventh Annual Canadian Computer Security Symposium, May 1995. • Hefner, R.; Hsiao, D.; Monroe, W., “Experience with the Systems Security Engineering Capability Maturity Model,” Proceedings of the International Council on Systems Engineering Symposium, July 1996. • Hosy, H.; Roussely, B., “Industrial Maturity and Information Technology Security,” Proceedings of the Seventh Annual Canadian Computer Security Symposium, May 1995. • Menk, C.G. III, “The SSE-CMM & Evaluations: Partners within the Assurance Framework,” Proceedings of the 1996 National Information Systems Security Conference, Oct 1996. • Zior, M., “Community Response to CMM-Based Security Engineering Process Improvement,” Proceedings of the 1995 National Information Systems Security Conference, Oct 1995.