安全策略与指标

1 级策略与指标

策略&与指标实践包含计划、分配职务和职责、确定软件安全目标、决定预算,以及确定指标和关卡。  

[SM1.1: 71] 发布流程(职务、职责和计划)并作必要完善。

向所有利益相关者通报处理软件安全的流程,以便所有人都知道相关计划。目标、角色、职责和活动得到明确界定。多数组织都会选择已发布的方法,例如 Microsoft SDL 或 Synopsys Touchpoints,然后再定制方法来满足自己的需求。SSDL 流程必须适应其管辖的开发流程(例如,瀑布、敏捷、CI/CD DevOps 等)的细节,因为它会配合组织和安全布局进行完善。流程必须经过发布才能有效。许多情况下,方法由 SSG 管控且只在内部发布。无需在公司以外公开推广 SSDL 就能取得预期影响。

[SM1.2: 66] 设立传播职务并开展内部营销。

SSG 指定人员必须担任传播角色,以便在整个组织构建软件安全支持。这种内部营销职能有助于保持高管和所有其他利益相关者随时了解软件安全问题的重要性及其解决方案的要素。例如,熟悉安全流程的敏捷指导员可以帮助团队在转变为敏捷方法时采用更好的软件安全实践。传播人员通常会与包括高管在内的内部团队进行会谈,向外部发言人发出邀请,为内部消费撰写白皮书,或者在内部网站上创建一系列文件、书籍和其他资源,并促进其使用。在盖茨备忘录发表之后,Michael Howard 的职务就是这种传播角色的典范。

[SM1.3: 67] 教育高管。

定期向高管展示软件安全不足的后果以及安全欠缺可能带来的负面业务影响。还要向他们展示别的企业怎样获得软件安全,包括处理未经监督就采用“当今特色”工程方法带来的风险。了解问题及其相关解决方案之后,高管就能支持将 SSI 作为风险管理的必要条件。最危险的方法是借助恶意黑客或公共数据泄漏事故的实例开展此类教育。SSG 最好在所有涉及因素均获许可的受控环境中(例如,如实展示遭到利用的情况及其业务影响)展示最坏的情况。某些情况下,向董事会演示有助于为正在开展的 SSI 争取资源。邀请外部大师通常有助于提升高管的关注度。将教育与移动或云服务等特定发展领域,或 CI/CD 和 DevOps 等特定方法联系在一起可以帮助说服领导层接受 SSG 建议,否则高管可能会偏好更快的发布时间或其他优先事项,而忽视这些建议。

[SM1.4: 101] 确定关卡的位置并收集必要工件。

软件安全流程包括 SDLC 中一个或多个点(更可能是多个 SDLC)的发布关卡/检查点/里程碑。建立安全专用发布关卡的前两步是确定与现有开发实践兼容的关卡位置,然后开始收集决策所需意见,决定是继续还是停止。重要的是,该阶段尚未实施关卡。例如,SSG 可以在发布之前收集每个项目的安全测试结果,但是不会判断什么因素构成充分测试或可接受测试的结果。在执行 CI/CD 的组织中看到的更短的发布周期往往需要创造性的方法来收集正确的证据,并严重依赖于轻量级,超快速的自动化。首先确定关卡,稍后再执行这一想法非常有助于推动软件安全的开发,而不会经历重大困难。交流推广关卡,并在多数项目已了解成功之道后再设立关卡。这一循序渐进的方法有助于促进形成良好的行为,而无需强求。

2 级策略与指标

[SM2.1: 47] 内部发布软件安全数据。

SSG 在内部发布数据,介绍组织内的软件安全状态,以便执行改善。这些信息可以采用面板的形式,为高管和软件开发管理人员提供度量标准。有时,这些发布内容并不会与公司的所有人员分享,而只是与相关高管分享。这时,就有必要向能推动组织作出改变的高管发布信息。其他情况下,秉承公开是最好的预防措施这一理念,执行开放式管理并向全体利益相关者进行数据发布有助于让所有人了解工作进展。如果组织的文化提倡团体之间开展内部竞争,这些信息就能为竞争增添一个安全维度。与 CI/CD 相关联的时间压缩需要快速准确地进行测量,测量时要较少关注历史趋势(例如,每个版本的缺陷)而更多关注速度(例如 修复时间)。

[SM2.2: 42] 通过测量执行关卡并追踪异常。

每个软件项目都执行了 SDLC 安全关卡:项目必须满足既定测量标准或取得豁免,才能通过一道关卡。即便是顽固的项目团队也必须遵守规则。SSG 追踪异常。项目要通过一道关卡,就可能需要接受代码审查并在发布之前修复任何重大问题。有时,关卡与法规、合同协议和其他业务责任所要求的控制措施直接相关,并且根据法定或监管推动机构要求跟踪异常。而有时,关卡的测量可产生用于管辖流程的关键性能指标。旋转门或橡皮图章意外流程不计入在内。如果有些项目自动通过,那就违背了执行关卡的目的。即便是看似无害的开发项目(例如现有后端的新移动客户端,或从内部数据中心移植到云环境的应用程序),也必须顺利通过规定的安全关卡,才能继续。同样,API、框架、库、COTS、微服务、容器配置等等都是必须通过安全关卡的软件。

[SM2.3: 44] 创建并培养卫星。

卫星始于分布在整个组织中的一群人,他们在安全方面的兴趣或技能高于平均水平。确定这个群体就向前迈进了一步,创建在软件开发中加快采用安全计划的社交网络。其中一种着手方法就是在入门培训课程中发现表现突出的人员(参见  [T3.6 通过培训确定卫星人员])。 另一种方法是招募志愿者。如果采用偏于自上而下的方法,则会指定最初的卫星成员,以确保全面覆盖所有开发/产品团队。应当根据实际表现确定是否保持成员资格。强大的卫星团队是 SSI 成熟的典型标志。在诸如移动开发等新兴或快速发展的技术领域或 DevOps 等开发模式中,卫星成员可以帮助将软件安全技能与可能在 SSG 中不具代表性的域知识结合起来。敏捷指导员能够组建特别得力的卫星成员。

[SM2.6: 39] 要求执行安全签核。

组织拥有在整个计划中执行的接受安全风险和记录问责的流程。风险接受者在发布之前签核所有软件的状态。例如,签名政策可能要求业务部门负责人签核尚未缓解的关键漏洞或已跳过的 SSDL 步骤。政策必须适用于外包项目(例如,精品店移动应用程序),以及要部署在外部环境中的项目(例如,云)。非正式或未经告知的风险接受本身并不被视为安全签核,因为接受风险的行为经过形式化(例如,签名、提交表单等等)并记录下来以备将来查阅时,会更为有效。同样,只是声明某些项目从不需要签核,无法取得预期结果。

3 级策略与指标

[SM3.1: 15] 使用内部追踪应用程序查看组合。

SSG 使用集中式跟踪应用程序来跟踪其各个软件(无论采用何种开发方法)在其范围内的进度。该应用程序会记录计划中、进行中和已完成的安全活动。它包含了架构分析、代码审查和安全测试等活动(即便它们发生在闭合环路中)的结果。SSG 使用追踪应用程序为其采用的多种指标生成组合报告。综合的库存和风险状况视图是最基本的。在许多情况下,这些数据至少都会在高管当中发布。这样会通过内部竞争产生有趣的效果,具体取决于公司文化。随着计划的逐渐成熟和活动的更加分散化,SSG 会使用集中式报告系统跟踪所有行动部分。

[SM3.2: 7] 运行内部营销项目。

SSG 帮助公司向外推销 SSI,以建立外部支持。软件安全的作用逐渐超出了降低风险的范围,而成为竞争优势或市场亮点。SSG 可能会撰写关于其 SSDL 的文章或书籍,或者拥有公开博客。它还可能参加外部会议或商贸展览。有时,可以对外发布并推广一套完整的 SSDL 方法。移动和云安全项目可以完成优秀的软件安全案例研究。对外分享细节并征求意见可以为公司带来新的视角。

[SM3.3: 18] 确定指标并以此促进制定预算。

SSG 及其管理层会选择指标,以定义和测量 SSI 的进展。这些指标将促进制定计划的预算和资源分配,所以仅靠简单的计数和统计是不够的。指标还让 SSG 能够量化解释其目标和进展。其中一个指标可能会是缺陷密度,其降低即表示补救成本逐渐下降。回想在敏捷方法中,早期收集的指标是最好的,并且通常都采用轻量化方式收集。这里的关键是通过明确而明显的方式将技术结果与业务目标联系起来,从而证明获得资金的合理性。因为安全概念对很多商业人士而言已微不足道,所以明确建立联系会有所帮助。