为了SDL概念的连贯性,你可以将本章的主要部分都当做软件开发过程的一个里程碑。例如,威胁建模发生在设计时,代码评审在实现之后,而安全测试发生在最终发行版本的alpha和beta测试期间。其他里程碑包括开发人员培训或者发行前安全审计/评审在合适的时候也可以使用。图10-12展示了覆盖了SDL里程碑(培训和威胁建模等)的虚构软件开发生命期。
图10-12 SDL实现示例
除了将安全当做现有开发过程上的覆盖层之外,更全面的过程设计对于长期的成功是很关键的。接下来,我们将设计一个完整的“安全工作流”来编排一些关键步骤。
我们在IT业界的许多经历中学习到,首先要避免的是“从头开始”综合症。在任何有能力的中到大型企业IT开发机构中,几乎肯定已经存在了一些基础支持架构。我们对希望建立强有力的Web安全计划的人们的第一个建议是:利用现有的资源!这涉及预先的认真研究。了解当前组织的应用开发质量保证(QA)过程的工作方式以及其中最有效的整合点。对于将要整合到生产应用支持过程的自动化工具来说这也同样重要,你必须理解当前运作的基础支持架构的工作方式,从数据中心中实际上接触服务器的“智能双手(Smart hands)”承包人,到在印度的电话银行工作的第1层支持承包人,通过第2层和第3层的系统工程师,一直传递到“第4层”最终在必要时接受升级的开发团队成员(以及他们的管理层)。认真思考你的评估方法和工具集和现有层次的整合方式,以及现有过程所需的一些重要调整的位置。
在我们的经验中,需要考虑的重要问题包括:
·管理层的理解与支持: 主管人员应该理解评估过程与整体业务风险管理计划的关系,全方位地予以支持(但是,不一定深入了解实施细节)。
·角色和责任: 管理层还应该清晰地理解对于评估计划发现的问题的组织责任。最明智的可能是遵循刚刚概述过的责任模型,从第×层的运营人员一直到给定应用的最高级执行“所有者”。
·安全策略: 这一策略应该简单、在组织中得到广泛理解,并且实际可行。最低限度,它应该描述计算标准、识别违反策略的关键条件,以及预计的弥补过程。安全策略还应该考虑相关的管理标准,如支付卡行业数据安全标准(Payment Card Industry Data Security Standard,PCI-DSS)。如果不存在好的策略,你就需要编写这样一个策略!
·与现有SDL的集成: 从Web安全方面的发现到开发人员的桌面之间,应该有一个精心记录相关缺陷类型和严重程度的途径。你还应该考虑在SDL中的不同时间点上评估的适用性(例如,投产之前和投产时)。
·IT故障标签系统: 如果你选择的自动化工具不能很好地集成,那么项目在开始之前就已经死亡。不要计划实施自己的“安全”标签系统——当你发现必须雇用重复的第1层支持人员来处理这些警告时,将会感到后悔。在部署投产之前要进行全面的测试和调整。
·事故响应过程: 如果没有严格的组织事故响应过程,你就必须尽快地催促管理层完成它。否则,安全团队在现有过程无法应付大量的警报时会显得笨拙。
·事后分析: 我们已经发现许多组织无法从事故或者过程失效中得到教训;确保你在整体计划中包含健全的事后分析过程。
·过程文档: 在我们的经验中,外部审计最常发现的问题是缺乏过程文档(我们有许多证据!)。别不把这当一回事——如果组织中还没有一个标准操作说明的可用存储库,那么就分配相关的资源创建一个。
·教育: 就像在软件开发人员的案头放上一本“安全编码”书籍并不能构成一个安全性SDL一样,在系统工程师的桌面上安装一个最新的应用安全扫描程序也是无效的。对所有级别的用户提供持续的系统使用培训,记录参与情况,测试对系统的理解,保持管理人员的责任心。
·有意义的衡量体系: 上面的所有建议都很好,但是假定你实施了所有或者部分建议,你如何知道它们的有效性?安全度量可能令人乏味,在任何一个学科中实现有意义的性能管理都很困难(更不用说软件开发了),但是对于确保有效的软件质量证明所需要的大量投资的回报来说没有更好的途径。不要畏缩,鼓励关键的利益方,谦虚、实际地推进这个体系。
显然,上述的这些只是很简短的概述,具体的主题可能相当复杂。我们希望这能让你开始对这些领域的进一步研究。