AWS教你如何做威胁建模

• 写在前面

• 准备威胁建模

  • 组建虚拟团队

  • 四个阶段的结构化思考

• 车联网威胁建模例子

  • 1、我们在做什么？为车辆登记功能创建系统模型

  • 2、会出什么问题？识别功能威胁

  • 3、我们要怎么做？确定威胁的优先级并选择缓解措施

  • 4、我们做得足够好吗？评估威胁建模过程的有效性

• 附录

  • 威胁建模模板

  • 参考资料

AWS教你如何做威胁建模

写在前面

    最近的“AWS re:Inforce 2022”介绍了众多的安全、身份和合规的产品和服务，笔者整理亚马逊相关资料一步一步介绍威胁建模环节该怎么做。

    这里严厉批评某些公司所谓的“轻量级威胁建模”，其实本质就是需求表格的自查，不要指望技术同学用简单的checklist就能做，想轻量级那就不是威胁建模！

    因为威胁建模的本质是----“有经验的安全专家和业务团队关于威胁的头脑风暴”，欢迎自动化、欢迎复用、欢迎标准流程，但威胁建模活动一定是以沟通、协作和以人为主导的专业知识为中心的。

准备威胁建模

组建虚拟团队

    威胁建模需要听取多种不同观点和经验才能进行，每个团队成员的意见都需要重视，最终在安全、交付、业务之间取得权衡。不能仅仅是安全和技术参与，checklist，卡点反而是阻碍威胁建模效果的瓶颈。具体来说需要五个角色：

• 威胁建模专家：是一次威胁建模活动的主导者，经验丰富、洞察威胁建模的过程和控制讨论边界，这个主持人、教练、顾问要参与一线，最终总结材料文档，平时同时兼职攻击者和防守者两个角色。

• 攻击者：发现设计类安全缺陷，类似于沙盘方式设身处地从攻击角度进行头脑风暴。

• 防守者：避免安全防御措施过度设计，设计威胁控制措施。

• 开发人员：主力模块开发者或者系统架构师，有了解当前服务具体如何设计和实现的背景，负责清楚明白威胁和缓解措施。

• 产品经理：类似于交付经理，避免安全措施导致产品需求无法实现，达到安全、效率和体验的平衡。

威胁建模的四个阶段

    通过在不同的阶段尝试结构化思考回答四个问题：

1. 我们在做什么？

参与者：全部虚拟团队成员

交付和设计更安全的软件

会出什么问题？

参与者：攻击者、开发者

<