威胁建模的本质:尽管通常我们无法证明给定的设计是安全的,但我们可以从自己的错误中汲取教训并避免犯同样的错误。

    首先需要知道什么样的设计是“安全的”,安全设计原则:
        开放设计——假设攻击者具有源代码和规格。
        故障安全预设值——出故障时自动关闭,无单点故障。
        最低权限——只分配所需的权限。
        机制经济性——保持简单、易懂的特性。
        分离权限——不允许根据单一条件执行操作。
        总体调节——每次检查所有内容。
        最低公用机制——注意保护共享资源。
        心理可接受性——他们将使用它吗?

    更进一步,设计完的系统应具有哪些安全相关的属性?
        机密性——数据只应限具有权限的人员访问。
        完整性——数据和系统资源只限适当的人员以适当的方式进行更改。
        可用性——系统在需要时一切就绪,可以正常操作。
        身份验证——建立用户身份(或者接受匿名用户)。
        授权——明确允许或拒绝用户访问资源。
        认可——用户无法在执行某操作后否认执行了此操作。

    使用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、使用预构建的威胁树可以确保不会忽略已知的攻击。

    总结:对于任何挑战,一个好的策略是将问题分解成若干更易于解决的小问题。关键一点是找到适合你的方法,较早将其应用于设计中,记住任何组件都可能失败,并进行必要的研究,以确保你已考虑了已知的攻击模式