持续威胁建模 | 169
5.4.3 做到什么程度
威胁建模中的一个常见问题是何时停止。你何时知道已经对系统进行了充分的
检查、足够的思考和充分的质疑,可以认为已完成任务?大家可能有过经历,
我们在半夜里醒来,突然意识到没有考虑到某个问题。你无须为有效地建立威
胁模型而产生偏执,但这有帮助。
在 CTM 中,问题的答案变得更加容易,因为根据定义,威胁模型是不断演进
的,并且仍有许多机会来进一步研究。但是这需要日常指导,经过深思熟虑和
反复试验后,当满足以下条件时,你应该认为威胁模型可以达到完成状态:
·
所有相关的图表都记录在文档中。
·
你在开发团队选择的跟踪系统中,以约定的格式记录了背景信息和发现。
·
威胁模型的副本存储在产品团队和安全团队共享的中央访问控制位置。
如果没有安全团队或安全专家进行审核,我们建议你选择一个具有安全意识的
团队成员作为安全“魔鬼代言人”,该成员将质疑威胁模型中的安全性假设,并
找出缓解措施的漏洞。这样,至少可以确保你已彻底检查了所有薄弱环节。
如果安全团队或专家准备提供帮助,则他们应该扮演教导和指导角色,致力于提高
产品团队的安全态势,而不是提出质疑。你可以通过在威胁建模期间对团队的绩效
提出建设性的批评,指出独特且可能面向产品的主题领域以进行进一步探索,并
确保开发团队检查所有关键领域,例如,身份验证和授权、加密以及数据保护等。
5.4.4 威胁模型的所有故事
至此,希望基线和基线分析能够解决系统状态等问题。但是,你如何解决系统
升级和威胁模型落后的问题?你如何避免在另一个开发周期结束时执行相同的
广泛基线测试?
不管你怎么看,只有一个因素负责将错误导入系统,那就是程序员。归根结底,
程序员决定了使用哪些参数、流程的执行顺序、数据去向等。这意味着,如果
你想解决一些问题,则必须在开发者级别解决。 ...