威胁模式是能够让隐藏的安全威胁和机制变成明显的威胁和机制的有效方式，这样安全人员就可以编写安全要求以及架构和测试安全工具。作为开始，笔者想使用STRIDE的修正版，它可以清晰的将威胁到机制绘制处理。这样的话，当开始新项目时(如SOA Web服务等)，我们就可以确定哪些标准可以帮助项目进行。
威胁 | 机制 | 示例标准 |
Spoofing | 验证 | WS-Security |
篡改数据 | 数字签名、Hash | WS-Security + XML Signature |
争议 | 审计日志 | 无 |
信息暴露 | 加密 | WS-Security + XML Encryption |
拒绝服务 | 可用性服务 | 无 |
特权的提升 | 授权 | 无 |
威胁模式通常都被误解了，他们并不是关于建构威胁的。作为防御性程序员，我们几乎不能控制威胁，我们的工作只是超出漏洞并修复漏洞。漏洞基本上是被动的系统缺陷，威胁是利用漏洞的各种操作，那么我们就能够1)确认威胁;2)处理威胁。威胁建模的最终结果不是威胁列表，而是解决方法的列表。并且不仅仅是通用列表，积极的威胁还能够帮助我们在架构中找出对策。
此外，如果我们对比构建软件的架构/设计早期阶段的方法，威胁模式其实是一种对比/比较的结构化方法。例如，如果我们正在建立一套Web服务并在SOA风格(WS-*)和REST风格间进行选择，我们可能会想看看每种软件安全栈支持的现行标准。
威胁 | 机制 | 示例SOA标准 | 示例REST标准 |
Spoofing | 验证 | WS-Security | XML Signature (仅响应) |
篡改数据 | 数字签名、Hash | WS-Security + XML Signature | XML Signature (仅响应) |
争议 | 审计日志 | 无 | 无 |
信息暴露 | 加密 | WS-Security + XML Encryption | XML Encryption (仅响应) |
拒绝服务 | 可用性服务 | 无 | 无 |
特权的提升 | 授权 | 无 | 无 |
威胁建模帮助我们将非常抽象的对象(如分析服务中的软件安全功能等)描绘出具体的结构，但是如你所见，威胁建模并不是关于威胁，而是关于安全架构元素。这只是个示例，并不是完整的威胁模型，但是它能够提供有效的的方式来查找安全架构中的问题。
文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/144253.html<
