网安加·百家讲坛 | 樊山：数据安全之威胁建模

作者简介：樊山，锦联世纪教育能源工业互联网数字安全CSM(新能源运维师)课程特聘培训讲师，哈尔滨工业大学（深圳）信飞合创数据合规联合实验室特聘专家，武汉赛博网络安全人才研究中心资深专家；近24年信息安全工作经验，熟悉网络架构设计、安全体系建设、风险治理、应急响应、内部威胁与治理、业务安全、数据安全、网络安全立法与供应链安全知识域；主持实施多项中国移动省地市公司多项信息安全规划、安全评估、安全审计项目；省级国地税安全规划与风险评估项目；主持实施多家政府机构风险评估和安全规划，历年来为多家大型企业重大网络安全事件提供顾问及事件分析服务，参与多项行业标准的编写。

1. 概述

威胁建模是一种系统化的方法，用于识别、评估和管理潜在的安全威胁，旨在开发和部署符合企业组织安全和风险目标的软件和IT系统。威胁建模建立在系统工程理论基础之上，以风险为驱动通过结构化的方式识别、评估和管理安全威胁。从而为有效实现“安全左移”的目标提供基础和支撑。

传统的威胁建模理论通常是建立在应用开发与系统建设之中，通过数据安全威胁建模实现数据安全工作，是针对威胁建模的一种延伸和发展，本文的目的是通过数据安全威胁建模从全业务链的角度分析数据威胁场景，提升组织全面审视数据安全风险的能力。全文从认识威胁建模、基于数据的威胁建模场景、威胁建模下的威胁地图三个层面分析数据威胁模型，从数据安全治理概述等方面出发，提供关于威胁建模的全面理解和实践指导。

2. 理解威胁建模

从传统风险评估而言，我们通常会从风险三大要素——资产、威胁和脆弱性来分析组织资产的风险状态。然而，受到诸多因素的影响，现有的风险评估工作往往侧重于脆弱性的识别与评估，忽视了威胁对脆弱性的利用能力，这导致了风险值受到脆弱性赋值的影响被过度放大，同时脆弱性的过度考虑还会导致风险的静态化问题。然而风险值并非一成不变，而是随着威胁环境的变化而动态调整。

例如，一个漏洞的存在并不意味着必然面临高风险，关键在于该漏洞能否被特定的威胁所利用。因此，将威胁与脆弱性相结合，进行动态风险评估，成为提升评估准确性的关键。威胁建模正是在此背景下应运而生，它通过将威胁前置实现安全左移，即在系统设计阶段便充分考虑安全需求，从而有效降低了安全风险。

在系统工程理论指导下，三同步建设（同步设计、同步建设、同步使用）成为确保系统安全性的重要原则。其中，同步设计尤为关键。系统架构师在设计阶段便需充分考虑风险场景，识别并评估潜在威胁，这也正是威胁建模的核心所在。威胁建模使威胁被前置，成为系统设计不可或缺的一部分。通过构建威胁模型，我们可以清晰地识别出系统面临的各种威胁，以及这些威胁可能利用的脆弱点。这不仅有助于提升系统的安全性，还能在开发过程中引导开发人员采取针对性的安全措施，实现安全左移。

威胁建模是一个结构化的过程，其核心在于识别安全需求、精确定位安全威胁和潜在漏洞。在数据安全与网络安全领域，威胁建模的应用尤为广泛。通过威胁建模，我们可以对系统进行全面的安全分析，识别出潜在的安全风险，并采取相应的补救措施。

3. 基于数据的威胁建模

3.1 数据威胁建模的目的

以数据场景为例，我们可以构建一个简单的威胁模型来评估身份证号等敏感数据的安全性。在构建数据模型时，我们需明确身份证号等敏感数据的业务逻辑与调用需求。在此基础上，我们可以对身份证号进行去标识化处理或加密处理，以确保其安全性。这一过程不仅有助于提升数据的安全性，还能为开发人员提供明确的安全指导。此外，威胁建模还能量化威胁和漏洞的关键性，并优先考虑补救方法。通过威胁建模，我们可以清晰地了解系统面临的各种威胁及其严重程度，从而制定出针对性的安全策略与措施。这有助于提升系统的整体安全性，降低安全风险。

在完成整体安全体系建设后，我们往往还需考虑是否需为数据安全增设额外的补偿性控制措施，如增设硬件、软件、固件或加强管理等。这些措施的实施，进一步凸显了威胁建模在构建安全体系中的复杂性与重要性。威胁建模不仅帮助我们识别并评估潜在的安全威胁，还促使我们思考如何更有效地融合情报、利用先进技术（如AI）来完善安全策略。威胁建模过程中，我们可能面临的首要挑战是系统的抽象化以及潜在攻击者的能力评估。这要求我们深入理解攻击者的目标、方法以及可能的威胁目录。随着技术的不断进步，威胁建模与情报的融合成为了一个重要的趋势。通过有效融合情报，我们可以更准确地预测和防范潜在的安全威胁。

同时，笔者注意到AI及大模型在处理海量数据、定义复杂场景方面的优势。尽管笔者对大模型持保留态度，但其处理能力和先天价值确实可以作为辅助手段，帮助我们完善威胁建模中对于海量场景的定义。这极大地减轻了人工工作的负担，提高了威胁建模的效率和准确性。

3.2 构建数据威胁模型

在构建威胁模型时，我们需要明确建模对象。无论是数据、软件还是系统，建模对象都必须是可见的实体。数据可能存在于不可见的逻辑组件中，但我们的建模对象应是承载实体数据的载体。这些载体可能包括数据库、文件系统等。在每个载体的基础上，我们需要分析其所承载的数据类型、表结构、字段以及记录（条目）的表现形式。

以数据流为例，流式数据在传输过程中通常不会产生从属关系，而是直接到达其目的地并完成存储、二次使用或转换等过程。在建立模型时，我们需要充分考虑数据作为载体在不同载体中的风险和价值。软件是调度数据的核心工具。数据不会自行移动或表达价值，它需要通过软件的调度关系来实现其最终价值。因此，在建立威胁模型时，我们需要深入分析软件如何调度数据、产生何种表达（如API）以及数据如何被传输（明文或密文）、通过何种信道（已知或隐蔽）进行传输。

特别需要注意的是，隐蔽信道可能并非总是由攻击者创建，很多时候它可能是开发者行为的结果。例如，在开发项目中，为了降低成本或实现特定功能，开发者可能会采用隐蔽信道来传输数据。这种行为虽然可能出于善意，但也可能带来潜在的安全风险。

在系统生命周期的不同阶段，数据安全建模的方法也会有所不同。我们可以基于数据全生命周期来建模，也可以基于业务逻辑所产生的数据观点来建模。选择哪种方法取决于我们自身的能力和需求。

在软件设计之初，我们就应该开始考虑数据安全建模的问题。通过深入分析数据在系统中的流动、存储和使用情况，我们可以更准确地识别潜在的安全威胁并制定相应的防范措施。这将有助于确保系统在整个生命周期内的安全性和稳定性。威胁建模所面临的挑战还包括场景化问题、复杂性问题等。

数据自身并非无懈可击。未加密的数据、不良的数据格式以及缺乏统一标准的数据，都可能成为潜在的漏洞来源。此外，数据质量、真实性以及因访问控制不当而产生的数据滥用问题，同样属于数据漏洞的范畴。因此，在构建数据安全体系时，我们必须深入理解数据漏洞的本质，并采取相应的措施加以防范。

3.3 威胁元素

在基于合规性的数据建设威胁建模的过程中要求我们在形成数据模型时，首先要明确威胁元素。从笔者角度分析，可以将威胁元素定义为威胁源、威胁能力和威胁周期三大方面。

威胁源主要分为人为和非人为两类。人为威胁源包括黑客、内部员工等，他们可能出于各种动机对数据进行攻击或滥用。而非人为威胁源则主要来自于自然环境，如自然灾害等可能对数据造成破坏的因素。

威胁能力则要考虑特征、工具和行为三个因素。在这一领域，存在着多种方法论，如ATT&CK、STRIDE等，它们为我们提供了定义和评估威胁能力的框架。基于这些方法论，我们可以根据威胁的动机和影响来定义威胁状态，从而更准确地评估潜在的安全风险。

威胁周期也是威胁建模中不可忽视的一环。它涉及到数据风险产生的频率和持续时间。例如，内部人员的滥用行为可能每天都在发生，而外部攻击则可能通过日志、态势感知等网络设备每月或每季度被检测到。因此，在形成威胁元素时，我们需要根据不同的威胁实体来分析其构成的威胁频率，以便采取相应的防范措施。

3.4 数据威胁建模思路

之所以强调基于数据的概念，是因为受美国《SP 800-154 Guide to Data-Centric System Threat Modeling》的影响。该标准提出了以数据为中心的系统建模方法，允许组织考虑每个需要关注的案例的安全需求，而不是仅仅依赖通用化的最佳实践建议。通过这种方法，我们可以更准确地识别潜在的安全威胁，并制定相应的防范措施。

以一个简单的实例来说明，当我们使用计算机输入内容时，我们需要考虑输入数据的正确性。如果因误操作产生了错误的数据体现，这将构成一个威胁。因此，在输入过程中，我们需要建立一个验证活动来证实数据的正确性。这种验证可以通过人工或自动化的方式实现。自动化纠错机制可以实时纠正输入错误，从而提高数据的准确性和安全性。

正如在甲方进行溯源工作时，一个显著的问题逐渐浮现：尽管我们部署了多种数据安全产品，如数据管理平台、数据审计系统、数据库审计工具等，并成功捕获了大量数据访问记录和轨迹，但这些记录往往难以准确区分正常行为与异常行为。这一现象引发了我们的深思。在实际操作中，这些系统每天可能记录数十万条数据访问记录，然而，令人遗憾的是，其中鲜有能够触发告警的异常行为。面对如此庞大的数据量，人工复核显然不切实际。因此，这些记录大多只能作为事后追溯的证据，而无法作为预防机制的支撑。这一现状使得威胁问题愈发普遍，亟需我们寻求更有效的解决方案。

在此背景下，以数据为中心的威胁建模提供了一种新的视角。该模型包含多个关键步骤，首要的是识别和描述需要关注的系统和数据。在这一阶段，我们必须明确建模对象，并深入了解数据的存储位置、传输方式以及触发机制。

▪ 首先，数据的存储位置是基础。然而，随着云计算的普及，数据的位置变得愈发复杂。用户需要明确数据存储在公有云、私有云、政务云等哪个云平台上，以及具体的资源池和物理位置。此外，动态迁移和数据存储的唯一性问题也不容忽视。一旦数据位置不明，就可能构成潜在的威胁。

▪ 其次，数据的传输方式同样关键。近年来，API在数据传输中的应用日益广泛，但这也带来了新的风险。API可能打破组织的网络体系，通过未知传送节点构成隐蔽信道。因此，我们需要密切关注数据的传输路径和节点，确保数据的安全传输。

▪ 最后，数据的触发机制也不容忽视。程序触发的数据传输可能涉及多个目的地，这可能导致数据泄露等安全问题。特别是在移动应用领域，静默状态下的数据连接和传输已成为一个严重的安全隐患。因此，用户应定期检查手机应用的网络连接情况，及时发现并处理潜在的安全风险。

除了上述方面，运行时保存在本地内存中的数据以及虚拟CPU处理的数据也值得我们高度关注。特别是在无人值守的自助终端等组件中，这些数据的安全风险尤为突出。因此，我们需要采取更加严格的安全措施来保护这些数据的安全。

在数据安全领域，我们不仅要关注存储在服务器上的数据，还需警惕那些存留在各类终端设备、缓存以及云接口API数据中的敏感信息。特别是cookie文件和session数据，尽管cookie通常与个人用户相关联，但session数据及其他内存数据（如缓冲数据）的安全风险更为严峻。这些内存数据可能包括交易缓冲、视频、图像或输入文本等，它们在使用过程中可能暂时保存在本地。

今年，我们对多个行业的终端进行了检查，发现即便在信息采集和提交完成后，部分缓存和留存数据仍可能存在于本地。这一现象揭示了数据不仅存在于服务器上，还可能通过物理连接（如键盘输入、打印机输出）和显示屏幕等渠道泄露，从而涉及到物理安全的问题。因此，设置物理安全措施成为保护数据安全不可或缺的一环。

接下来，我们需要识别数据如何在系统内的授权位置之间移动。在部署安全策略时，我们通常会明确指定数据的流动路径和访问权限。例如，在数据库服务器的IP策略中，我们可以规定应用服务器与数据库服务器之间的通信规则，确保只有经过授权的数据流才能通过。对于跨网段的数据传输，我们则需要在企业级防火墙上配置相应的安全策略，以隔离和监控数据的流动。

数据在计算机系统内部的流转过程同样值得我们关注。从输入数据到虚拟内存的接收，再到CPU的处理和回送到外层显示，每一个环节都可能成为数据泄露的潜在风险点。特别是在云主机环境下，数据的流转过程可能更加复杂和难以追踪。因此，我们需要明确数据在云端或本地发生的处理过程，并检查记录文件是否包含数据本身的内容，以便及时发现并应对潜在的安全威胁。

在构建威胁建模场景时，我们还需关注数据的安全属性。机密性、完整性、可用性、真实性、可靠性以及抗抵赖性等属性都是评估数据安全性的重要因素。例如，在工业控制领域，数据的可用性和完整性可能更为关键。因此，在建模过程中，我们需要详细描述可能影响数据可用性和完整性的所有威胁场景，并制定相应的安全策略来应对这些威胁。同时，我们也应避免陷入一个误区：即过度考虑风险场景的数量，而忽视了构建完整模型的重要性。通过明确数据的安全属性和威胁场景，我们可以更有效地评估和管理数据安全风险，为构建安全、可靠的数据环境提供有力支持。

在探讨数据安全与威胁建模的过程中，我们已明确指出，借助人工智能（AI）与大模型技术来构建威胁模型具有显著潜力。然而，这一进程的实现需要大量的开发工作作为支撑。从建模的角度出发，我们建议先通过项目实践验证模型的有效性，确保其在实际应用中能形成可落地、高质量的最佳实践。在此基础上，我们再进一步探讨如何将这些模型产品化，以供更广泛的行业应用。这一步骤的实施，将依赖于各厂商的支持与合作，而我们则愿意开放我们的模型供行业同仁参考与使用。

在识别影响安全目标的方式时，我们需重点关注涉及数据的人员与流程。首先，要明确谁将访问数据，这是构建威胁模型的基础。理想的访问人员分类应从访问者（用户）的角度出发，进一步细化为不同级别、不同地域的用户，以便根据用户场景判断其访问目的与意图。同时，我们还需区分维护者的角色，包括系统维护者与业务维护者，并关注他们执行维护的方式（本地或远程）。在此过程中，我们应明确数据操作权限的分配，如系统管理员仅负责数据的备份与规则恢复，而业务管理员则负责数据的优化、清理与处置。

随着技术的发展，我们越来越多地发现实体身份的模糊化趋势。在某些场景下，数据的调度关系并非人与机之间的人机会话，而是设备与设备之间基于程序规则的自动调度。这种设备间的会话虽然减少了人为干预，降低了机密性泄露的风险，但如何确保数据完整性的保障成为新的挑战。这包括通信传输中的延迟、两端数据处理性能不一致导致的时序关系错乱等问题。

因此，在构建威胁模型时，我们需要综合考虑模型的深度与广度，确保覆盖所有潜在的威胁场景。

4. 威胁建模下的数据威胁地图

识别和选择要包含在模型中的攻击向量是建模过程中的关键步骤。在构建模型属性与威胁状态值时，我们应自觉地将攻击向量纳入考虑范围。这要求我们在产生实体间关系集时，就预先设定可能的攻击路径与手段。虽然初步设定的攻击向量可能数量庞大，但通过后续的优化与讨论，我们可以筛选出最具威胁性的向量，并将其纳入威胁库表以备后续使用。

4.1 构建数据威胁地图

攻击向量是攻击者用来访问漏洞的完整路径的一部分，包括攻击来源、潜在受攻击的处理者以及恶意内容本身。在明确攻击向量的基础上，我们需描述用于减轻这些攻击向量的安全控制措施。例如，针对通过无线网络连接打印机的攻击场景，我们可以采用传输保护技术来确保数据的机密性与完整性。

物理环境保护与设备认证构成了安全防线的基石。设备认证机制，简而言之，即确保只有经过身份验证的用户或设备才能访问或操作特定资源。以打印场景为例，当用户发送打印指令至打印机后，打印机虽已完成打印任务，却暂不输出纸张，而是将其保存在内部。此时，用户需通过刷卡等身份验证手段，方能激活纸张输出，这一流程彰显了数据机密性的保护原则。我们必须认识到，此机制主要聚焦于数据的机密性，而未全面涵盖数据的完整性和可用性。

例如，若攻击者干扰无线AP信号，用户打印出的内容可能呈现乱码；或攻击者直接破坏打印机，导致打印任务失败。因此，针对不同安全属性的需求，我们必须构建差异化的威胁场景，并制定相应的控制措施。

在制定消减手段时，需综合考量多种因素，包括投入成本、控制效能及产生的安全性水平。需要明确的是，绝对的安全是不存在的。无论我们采取何种安全手段，都存在一定的风险。我们所追求的，是在组织可接受的范围内，最大限度地降低安全风险，这便是安全的最终愿景。

在构建威胁模型时，我们需基于采购成本、维护成本及对功能和性能的影响，审慎选择适宜的错误控制措施。以笔者所构建的虚拟业务逻辑为例，该逻辑明确了数据的主要载体，包括客户端、短信网关、防火墙、应用服务器、认证服务器及数据库服务器等。同时，我们根据这些载体的特性，将其划分为用户域、服务域和第三方服务域，以便更精准地识别和管理风险。

图1.数据威胁地图

在深入分析数据的安全属性时，我们需关注机密性、完整性、可用性、抗抵赖性和真实性等方面。在构建威胁模型时，可以采用不同颜色的标识来区分不同的安全属性，以便更直观地展示潜在威胁。此外，还可以细化数据描述，如数据库表、半结构化数据、cookie文件等，以便更深入地理解数据流动过程中的安全风险。

▪ 在数据库服务器方面，其存储的结构化数据是系统最核心的保护对象。应用服务器则处理半结构化数据，这些数据在请求过程中会经历格式转换。认证服务器在完成认证后，理论上应清除相关数据，以避免潜在风险。然而，在实际操作中，若数据未被及时清除，便可能成为攻击者的目标。

▪ 在数据传输过程方面，无论采用加密信道还是非加密信道，都无法完全阻止嗅探攻击。但加密传输至少能确保攻击者即使嗅探到数据，也无法轻易解密。相比之下，明文传输则存在数据被直接窃取的风险。因此，在数据传输过程中，我们必须采用加密手段来保护数据的机密性。

▪ 在短信网关等第三方服务方面，也可能成为攻击者的目标。针对这类服务，我们需明确其业务逻辑和数据流动过程，以便更准确地识别潜在威胁。同时，我们还需关注用户域和服务域内的安全风险，如机密性破坏、键盘记录攻击等。

▪ 在数据库服务器威胁方面，除了外部攻击风险外，还需警惕内部威胁。例如，不良的数据接口关系可能导致认证攻击；授权过度则可能使攻击者获得不应有的权限；基于应用在调度数据活动中形成的功能模块授权过渡也可能引发安全风险。若将数据库服务器部署在云端，还需叠加考虑云风险，如SARS攻击、密码逃逸等。

因此，我们必须认识到，任何实体的威胁都是动态的，而非静态的。在不同的物理环境中，所产生的威胁可能截然不同。我所阐述的仅是方法论，而非最佳实践。在使用这些方法论时，我们需根据具体环境进一步执行相应的补偿和增强型威胁模型建设。针对数据自身的问题，如虚假数据、数据欺骗、滥用和脏数据等，我们也需制定相应的防控措施，以确保数据的安全性和完整性。

在数据安全领域，我们不仅需关注数据载体本身的安全，还应深入分析数据传递过程中各组件的潜在风险。本部分将聚焦于非数据载体，特别是防火墙等关键组件，探讨其可能遭受的账号攻击及对数据安全的影响。

防火墙作为数据传递的关键节点，其配置文件及流经的网络流文件虽非数据库服务器的直接数据，却同样面临安全威胁。攻击者可能通过针对性攻击，利用这些数据提前获取对防火墙的控制权，进而威胁整个数据流转过程的安全性。因此，在讨论数据安全时，我们不可忽视这些非数据载体的安全属性。

4.2 建立数据威胁表单

为了更直观地展示威胁建模的过程与结果，我们将复杂的图表转化为结构化的表格。该表格涵盖了用户域、服务域、第三方服务域中的各类组件，包括PC通信、边界防火墙、应用服务器、认证服务器、数据库服务器及短信网关服务器等。表格详细列出了这些组件的位置、存储形式、数据类型、安全属性，以及攻击向量描述和对抗手段，为威胁建模提供了清晰而全面的视角。

值得注意的是，随着组件、位置及环境的变化，攻击向量也会相应调整。例如，当用户域的PC终端转变为云终端时，存储位置由外存变为云端，攻击向量也随之增加，需考虑云自身的安全威胁。同样，数据库服务器若采用存储服务器分离的模式，其存储位置及攻击向量也会发生相应变化。

在构建威胁模型时，我们应确保模型的灵活性与适应性，能够动态地增加或减少评估项，以适应不同的安全需求与环境变化。同时，为了提升威胁建模的专业性与可封装性，建议参考成熟的威胁模型框架，如微软的STRESS或ATT&CK。这些框架不仅提供了全面的威胁场景与攻击手段，还能帮助我们在建模过程中保持条理清晰，避免遗漏关键信息。

5. 威胁模型视角下的数据安全治理概述

在威胁建模的基础上，我们需进一步构建相应的安全控制措施。以NIST SP 800-171为例，该标准详细列出了17个安全控制类别，为数据安全评估提供了有力参考。在实际应用中，我们可根据具体需求与场景，对这些控制类别进行裁剪与调整，以确保评估的精准性与高效性。

图2.数据风险安全控制类别

在数据安全风险评估中，账户管理是一个尤为关键的环节。由于边界网关设备、堡垒机、4A等系统主要管控的是服务器访问权限，而非数据访问权限，因此我们在数据安全领域应更多地关注应用服务账号对数据访问能力的评价。此外，审计问责也是数据安全评估中的重要一环。我们需明确审计目标，记录并识别审计记录，对可识别记录作出判断，以避免数据安全事件的恶化。

最后，配置管理同样不容忽视。我们应确保配置策略不仅针对功能使用，还应涵盖数据访问权限。例如，在导出用户数据的功能中，我们应细化功能组与用户组，确保只有具备相应权限的用户才能执行数据导出操作，以避免数据泄露风险。