文摘，原文地址：https://msdn.microsoft.com/zh-cn/magazine/cc163519.aspx
威胁建模的本质：尽管通常我们无法证明给定的设计是安全的，但我们可以从自己的错误中汲取教训并避免犯同样的错误。
首先需要知道什么样的设计是“安全的”，安全设计原则：
开放设计——假设攻击者具有源代码和规格。
故障安全预设值——出故障时自动关闭，无单点故障。
最低权限——只分配所需的权限。
机制经济性——保持简单、易懂的特性。
分离权限——不允许根据单一条件执行操作。
总体调节——每次检查所有内容。
最低公用机制——注意保护共享资源。
心理可接受性——他们将使用它吗？
更进一步，设计完的系统应具有哪些安全相关的属性？
机密性——数据只应限具有权限的人员访问。
完整性——数据和系统资源只限适当的人员以适当的方式进行更改。
可用性——系统在需要时一切就绪，可以正常操作。
身份验证——建立用户身份（或者接受匿名用户）。
授权——明确允许或拒绝用户访问资源。
认可——用户无法在执行某操作后否认执行了此操作。
使用STRIDE方法来进行威胁建模，确保应用具有这些安全属性。STRIDE是指：
Spoofing(假冒) 对应 身份验证。
Tampering(篡改) 对应 完整性。
Repudiation(否认) 对应 认可。
Information Disclosure(信息泄露) 对应 机密性。
Denial of Service(拒绝服务) 对应 可用性。
Elevation of Privilege(提升权限) 对应 授权。
使用数据流关系图(DFD)来辅助STRIDE分析，将系统分解成部件，并证明每个部件都不易受相关威胁攻击。DFD正确是确保威胁模型正确的关键所在。FDF包含如下元素：
数据流：通过网络连接，命名管道，RPC通道等移动的数据。
数据存储：表示文件，数据库，注册表项以及类似项。
进程：计算机运行的计算或程序。
交互方：系统的端点，例如人，web服务器和服务器。
信任边界：表示可信元素与不可信元素之间的边界。
在应用STRIDE进行威胁建模分析时，需要注意的问题点：
1、客户可能从来不会明确提出某些安全性的要求，因此，设计人员必须找到问题描述中内在的安全性要求。
2、不仅必须从一个攻击者的角度来看待风险问题，还必须“同时”从所有的攻击者的角度来全盘考虑安全问题。
3、DFD是否切合实际的常规判断依据：
第一，数据不是凭空臆造的，确保对于每个数据存储，都有读取者或写入者。
第二，注意数据传输过程的灵魂作用，确保始终有一个进程读取和写入数据。
第三，将单个信任边界内的相似元素收缩为单个元素，以便于建模。
第四，注意信任边界任一侧的建模细节，尝试显示更详细的信息。
4、信任边界的真正定义——不相信另一端的任何事物。
5、你根本想象不到其他人为何需要你的数据，你只需认为有人需要你的数据。
6、你与客户相距越远，就越难以知道客户对于不同风险的承受程度。不要对客户的情形或风险承受程度做过多的假设。
7、攻击者可能是内部人员，而不是外部人员。他们可能具有合法的访问权限，可以访问数据库以完成自己的工作。
8、针对每个威胁和DFD中的每个元素进行分析：针对所有数据流和数据存储解决了篡改、信息泄露和拒绝服务威胁；针对所有进程解决了所有STRIDE威胁；针对所有交互方解决了假冒和否认威胁；并解决了影响信任边界的独特威胁。
9、STRIDE模型很好的一点在于，它能让你洞察你所需的抑制措施的本质。
10、使用预构建的威胁树可以确保不会忽略已知的攻击。
总结：对于任何挑战，一个好的策略是将问题分解成若干更易于解决的小问题。关键一点是找到适合你的方法，较早将其应用于设计中，记住任何组件都可能失败，并进行必要的研究，以确保你已考虑了已知的攻击模式