第17章 安全开发流程（SDL）

17.1 SDL简介

安全开发是从根源有效地解决安全漏洞问题，而已在软件的生命周期内，这样的开发模式成本更低。

SDL过程：

q  培训

所有的开发人员必须接收适当的安全培训，了解相关的安全知识。

q  安全要求

明确项目的安全要求。

q  质量门/bug栏

质量门和bug栏相当于确定安全和隐私质量的最低可接受级别。

q  安全和隐私风险评估

评估项目中的安全现状和威胁模型

q  设计要求

在产品设计初期考虑安全问题

q  减小***面

减小***面通过减少***者利用潜在弱点或漏洞的机会来降低风险。减少***面包括关闭和限制对系统服务的访问，应用“最小权限原则”，以及尽可能的进行分层防御。

q  威胁建模

建立威胁模型分析项目或产品可能遇到的***，以及给出解决方案

q  使用指定的工具

q  弃用不安全函数

q  静态分析

q  动态程序分析

q  模糊测试

模糊测试是一种专门形式的动态分析，它通过故意想应用程序引入不良格式或随即数据诱发程序故障。

q  威胁模型和***面评析

需求发生改变时，安全模式也需要相应改变

q  事件响应计划

产品的发布需要留下开发人员的联系方式，以及相应的文档，方便日后解决问题。

q  最终安全评估

q  发布/存档

17.2 敏捷SDL

敏捷sdl的思想其实就是以变化的观点实施安全的工作。需求和功能可能一直在变化，代码可能也在发生变化，这要求实施SDL时需要在每一个阶段更新威胁模型和隐私策略，在必要的环节迭代模糊测试、代码安全分析等工作。

17.3 SDL实战经验

准则：

q  与项目经理进行充分的沟通，排出足够的时间

q  规范公司的立项流程，确保所有项目都能通知到安全团队，避免遗漏

q  树立安全部门的权威，项目必须由安全部门审核后才能发布

q  将技术安放写入开发、测试的工作手册

q  给开发工程师培训安全方案

q  记录所有的安全bug，激励程序员编写安全的代码

 

17.4 需求分析与设计阶段

应该建立安全编程的代码库，以及一些比较常见的安全编码问题。

17.5 开发阶段

Sun 的安全编码指导方针:

q  小心使用 特权代码

q  小心处理 静态字段

q  最小化作用域 (scope)

q  小心选择 公共 (public) 方法和字段

q  适当的 包 (package) 保护性

q  尽可能使用 不可变 (immutable) 对象

q  永远不要返回对包含敏感数据的内部数组的引用

q  永远不要直接存储用户提供(user-supplied)的数组

q  小心使用序列化(Serialization)

q  小心使用本地方法(native methods)

q  清除敏感信息

 

Java 安全反模式

q  忽略那些全模式的代码不经意间就会造成漏洞

典型的 Java 安全编码反模式(Antipatterns):

忽略语言特性 (例如整数溢出 (Integer Overflow) )

不注意使用序列化, 不注意使用 特权代码

将字段和方法定义到不适当的可见性作用域

在非终态 (non-final) 静态字段中的隐蔽通道(Covert  Channels)

 

 

17.6 测试阶段

参考资料：http://blog.csdn.net/Test_sunny/article/details/4653783

              http://51CTO提醒您，请勿滥发广告!/ceshi/ceshijishu/aqcs/2013/0715/206456.html

              http://51CTO提醒您，请勿滥发广告!/ceshi/ceshijishu/aqcs/2012/0329/204547.html