安全功能与设计

安全功能& 设计实践负责为主要安全控制措施(满足标准和要求实践中定义的标准)创建可用的安全模式,为这些控制措施建立中间件框架,以及创建和发布其他前瞻性安全指导。

1 级安全功能与设计

[SFD1.1: 95] 构建并发布安全功能。

有些问题只有一步到位才能得到最好的解决。SSG 并没有让每个项目团队都实施自己的所有安全功能(例如,认证、角色管理、密钥管理、审核/日志、加密和协议),而是通过构建和发布其他组使用的安全功能来提供前瞻性指导。通用安全功能通常需要针对特定平台(如移动设备)进行量身定制。例如,移动加密功能如果使用底层系统调用,则至少需要两个版本才能覆盖 Android 和 iOS。项目团队可以从 SSG 预先认可的实施中受益,SSG 的优势在于不必反复追踪常常潜入安全功能的细微错误。SSG 可以确定自己青睐的实现并将其作为合格解决方案进行推广。

[SFD1.2: 70] 将 SSG 与架构相结合。

安全是组织软件架构讨论时的必谈话题,架构团队除了负责性能、可用性或可扩展性之外,同样担负着安全责任。防止本次讨论脱离安全主题的一种方法是让 SSG 出席例行架构会议。此外,企业架构可以帮助 SSG 创建有机整合到企业设计标准中的安全设计。SSG 主动参与是成功的关键所在。例如,将一个为人熟知的系统迁移到云上则需要再次聘请 SSG。别作任何假设。  

 

2 级安全功能与设计

[SFD2.1: 34] 构建利用设计中间件框架和通用库保障的安全。

SSG 针对利用设计中间件架构或通用库构建的安全,构建或提供建议,从而在软件设计中发挥主动作用。除了示例教学之外,这一中间件还协助架构分析和代码审查,因为构建模块有助于轻松发现错误。例如,SSG 可以修改一个热门网络框架(例如 Spring),使其易于满足如何输入验证要求。最后,SSG 可以专门针对其提供的组件定制代码审核规则。采用中间件框架(或任何其他使用广泛的软件)时,请务必在发布之前仔细审查安全性。鼓励采纳和使用不安全的中间件不利于改善软件安全状态。通用开源软件安全架构(包括 OWASP ESAPI)不应被视为设计安全。最后通过调用库来强制实施安全不是安全设计的方法。

[SFD2.2: 46] 创建 SSG 职能来解决复杂设计问题。

SSG 尽早参与新的项目流程,能够为新架构贡献力量并解决复杂设计问题,尽量减轻安全对于其他约束(上市时间、价格等)的不利影响。SSG 派遣参与设计新协议的技艺娴熟的架构人员可以分析现有协议的安全影响,并确定应该复制或避免的元素。同样,让安全架构人员了解将一个似乎为人熟知的应用程序迁移到云上而产生的后果,能够避免大量的后续麻烦。预先设计安全性比先分析现有的安全设计,再在发现缺陷时进行重构的做法更加高效。当然,即便是最优秀的专家也无法通过扩展解决整个软件产品组合的所有需求。有些设计问题需要超出 SSG 范围的特定知识。  

3 级安全功能与设计

[SFD3.1: 9] 形成审查委员会或中央委员会以审批和维护安全设计模式。

审查委员会或中央委员会正式确定在设计需求和安全权衡方面达成共识所需的流程。与架构委员会不同,这一团体专门提供安全指导,还定期审查已经发布的(特别是围绕密码学的)设计标准,以确保设计决定不会陈旧无用。此外,在通常因为采用新技术而引发的混乱中,审查委员会也有助于掌控局面,无需 SSG 的参与即可引导深陷泥沼的开发团队走出迷局。

[SFD3.2: 9] 必须使用合格的安全功能和框架。

实施人员必须在合格清单中选择安全功能和框架。这项活动有两个好处:开发人员不花时间重新实现现有的功能,审查团队不必在新的项目或采用新的平台时对付与以往相同的缺陷。尤其是,项目使用合格组件越多,架构分析和代码审查就越容易(参见 [AA1.1 执行安全功能审查])。重用是一致的软件架构表现的重大优势,对于敏捷开发和维持 CI/CD 管道的速度尤其实用。

[SFD3.3: 2] 寻找并发布组织的成熟设计模式。

SSG 通过收集整个组织的设计模式并发布给每个人使用,促进集中式设计重用。SSG 网站的一部分会推广架构分析过程中确定的积极元素,传播好的创意。该流程应当正式确定:仅靠临时性事故通知是不够的。有时,中央架构或技术团队会协助并改善该活动。采用通用设计模式能够加快软件的构建,例如运用安全设计模式,而不止是应用(包括微服务、API、框架、基础架构和自动化)。