“为了减少产品设计带来的安全隐患,避免后续发现问题时,对功能实现流程甚至程序架构大刀阔斧改动带来高昂代价。在产品设计阶段,需要加入必要的安全活动,减少并消除产品安全隐患,纵深提升业务安全能力。”
01
—
安全目标
安全团队可以通过引导相关责任人进行自检,要求输出安全检查结果,并推动落实安全整改项来开展安全活动。在此过程中,需关注以下四个基本要素:
02
—
安全活动
在产品设计阶段,安全活动主要围绕设计要求、减小攻击面和威胁建模展开。
1)确定设计要求
从隐私和安全角度两方面进行考虑:
2)减少攻击面
尽量减少暴露给恶意用户可能访问到的程序相关资源,包括但不仅限于端口、接口、服务、协议。
3)威胁建模
威胁建模是一种分析应用程序威胁的方法,可识别潜在的安全问题并实施相应解决或缓解措施。通常使用微软提出的STRIDE威胁等级分类法,将威胁分为:Spoofing(仿冒)、Tampering(篡改)、Repudiation(否认)、Information Disclosure(信息泄漏)、Denial ofService(拒绝服务)和 Elevation ofPrivilege(权限提升)六部分。
上述六大威胁所表示的定义、安全属性、消减措施可参照下表:
此外微软官方还提供了免费的威胁建模工具,可作为平时研究使用。
03
—
安全实践
在实际的安全活动中,一般采用安全设计checklist + 威胁建模的模式。
由此,安全设计checklist便是安全设计阶段的重中之重。一套好的安全检查项,并不是大而全,而是小而精且有效、业务方好理解。关于安全设计checklist的设计与内容,除了紧贴设计要求、安全编码规范、安全测试等后续安全活动反哺外,还可以参照一些互联网上的优秀案例。比如,美的金融SDL安全设计checklist:
又如,VIPKID产品设计与开发安全红线:
此外,还可以针对角色的不同,制作内容一致表现形式不同的安全检查项。比如从业务方视角:
又如,从安全角度出发:
04
—
持续优化
安全设计需要一定的积累和尝试,才能总结出一套可落地、有效的安全流程与解决方案。在实践过程中,发现一些比较行之有效的做法:
1)宣贯会上搜集业务方切身需求与体会
通过定期召开“安全评估流程”宣贯,不断搜集来自前端开发、后端开发、产品设计人员等不同参与人员的建议,持续优化现有安全设计checklist。
2)从后续安全活动中吸取经验,反哺安全设计检查项
在其后的环节,特别是代码审计和安全测试发现的漏洞与安全缺陷,可以反推到安全设计阶段,不断优化、持续补强针对某一重要系统或某一通用功能的专属安全设计checklist。
3)扩大相关责任人范围,衔接安全开发
如果仅聚焦于产品设计师可能带来的安全问题,往往难以满足在该阶段的期望(产品设计师输出产品功能原型图、业务流程图,具体功能实现便交由开发)。从降低安全活动带来的成本与打通SDL流程的角度考虑,需要将安全编码的理念提前一部分加入到安全设计阶段,因此该阶段关注的人物对象便是产品设计人员、开发人员。