写在前面
准备威胁建模
组建虚拟团队
四个阶段的结构化思考
车联网威胁建模例子
1、我们在做什么?为车辆登记功能创建系统模型
2、会出什么问题?识别功能威胁
3、我们要怎么做?确定威胁的优先级并选择缓解措施
4、我们做得足够好吗?评估威胁建模过程的有效性
附录
威胁建模模板
参考资料
AWS教你如何做威胁建模
写在前面
最近的“AWS re:Inforce 2022”介绍了众多的安全、身份和合规的产品和服务,笔者整理亚马逊相关资料一步一步介绍威胁建模环节该怎么做。
这里严厉批评某些公司所谓的“轻量级威胁建模”,其实本质就是需求表格的自查,不要指望技术同学用简单的checklist就能做,想轻量级那就不是威胁建模!
因为威胁建模的本质是----“有经验的安全专家和业务团队关于威胁的头脑风暴”,欢迎自动化、欢迎复用、欢迎标准流程,但威胁建模活动一定是以沟通、协作和以人为主导的专业知识为中心的。
准备威胁建模
组建虚拟团队
威胁建模需要听取多种不同观点和经验才能进行,每个团队成员的意见都需要重视,最终在安全、交付、业务之间取得权衡。不能仅仅是安全和技术参与,checklist,卡点反而是阻碍威胁建模效果的瓶颈。具体来说需要五个角色:
威胁建模专家:是一次威胁建模活动的主导者,经验丰富、洞察威胁建模的过程和控制讨论边界,这个主持人、教练、顾问要参与一线,最终总结材料文档,平时同时兼职攻击者和防守者两个角色。
攻击者:发现设计类安全缺陷,类似于沙盘方式设身处地从攻击角度进行头脑风暴。
防守者:避免安全防御措施过度设计,设计威胁控制措施。
开发人员:主力模块开发者或者系统架构师,有了解当前服务具体如何设计和实现的背景,负责清楚明白威胁和缓解措施。
产品经理:类似于交付经理,避免安全措施导致产品需求无法实现,达到安全、效率和体验的平衡。
威胁建模的四个阶段
通过在不同的阶段尝试结构化思考回答四个问题:
我们在做什么?
参与者:全部虚拟团队成员
交付和设计更安全的软件
会出什么问题?
参与者:攻击者、开发者