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

作者简介：樊山，锦联世纪教诲能源工业互联网数字安全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等系统紧张管控的是服务器访问权限，而非数据访问权限，因此我们在数据安全范畴应更多地关注应用服务账号对数据访问本事的评价。别的，审计问责也是数据安全评估中的紧张一环。我们需明确审计目标，记录并识别审计记录，对可识别记录作出判断，以制止数据安全变乱的恶化。
最后，设置管理同样不容忽视。我们应确保设置策略不仅针对功能利用，还应涵盖数据访问权限。例如，在导出用户数据的功能中，我们应细化功能组与用户组，确保只有具备相应权限的用户才气实验数据导出操作，以制止数据泄露风险。

图3.数据风险评估类别详解1

图4.数据风险评估类别详解2

数据安全与威胁建模是一个复杂而细致的过程，需要我们深入分析数据流转过程中的各个环节与组件，构建灵活、适应性强的威胁模型，并接纳相应的安全控制步伐，以确保数据的机密性、完整性与可用性。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。