摘要：软件系统面临着各种各样的威胁，而且威胁数量随着技术的变化而增加，威胁可能来自组织外部或内部，它们可能会造成破坏性后果。可以使用威胁建模方法来结构化识别威胁并构建防御措施。但是传统的威胁建模流程较为繁琐，对于安全人工投入要求较高，很难适应业务的敏捷快速迭发。因此，本课题基于DevSecOps理念和实践，对威胁建模过程进行优化，提出场景化轻量级威胁建模框架，实现自助化、工具化及自动化的攻击面分析及威胁建模，提升威胁建模效率，适应DevOps的快速交付节奏。

　　在软件全生命周期的各个阶段都面临着相应的安全挑战，如不安全的设计、代码安全漏洞、部署环境未加固等。越早发现安全漏洞，修复的成本越低，“安全左移”已经是一种共识。在软件安全开发生命周期SDL方中，威胁建模是软件开发设计阶段执行的主要安全活动之一。威胁建模通过识别威胁、理解信息系统的安全风险，发现信息系统设计中的安全问题，制定消减措施，并将消减措施落入信息系统设计中。通过威胁建模活动可以在早期阶段发现安全缺陷，理解安全需求，设计和交付更安全的产品，因此具有重要的价值。

　　传统的威胁建模流程较为繁琐，对行业应用安全从业者提出了非常高的要求，且难以工具化、自动化并适应业务的敏捷快速迭发。因此，本课题基于DevSecOps理念和实践，对威胁建模过程进行优化，提出场景化轻量级威胁建模框架，可以实现自助化、工具化及自动化的攻击面分析及威胁建模，提升威胁建模效率，适应DevOps的快速交付节奏。

　　威胁建模是分析应用程序安全性的一种结构化方法，通过识别威胁，定义防御或消极威胁控制措施的一个过程。威胁建模属于微软SDLC中核心部分，微软一直是这一过程的强有力倡导者。威胁建模应该在软件开发生命周期的早期进行，因为这样可以及早发现并修复潜在问题，从而防止后续修复成本更高。使用威胁建模来考虑安全需求可以带来主动的架构决策，从一开始就有助于减少威胁。

　　STRIDE评估系统详细设计。首先对系统建模，通过构建数据流图 (DFD)，可以识别系统实体、事件和系统边界。准确的 DFD决定了STRIDE 的成功程度。

　　STRIDE 使用一组通用的已知威胁，STRIDE 代表仿冒、篡改、抵赖、信息泄露、拒绝服务和特权提升，该首字母缩略词可用作发现威胁的助记符，如下图所示。

　　STRIDE方法易于采用，但可能很耗时。STRIDE 的主要问题是，随着系统复杂性的增加，威胁的数量会迅速增加。即使 Microsoft 不再维护 STRIDE，它仍作为 Microsoft 安全开发生命周期 (SDL) 的一部分使用威胁建模工具（Threat Modeling Tool）实现，该工具仍然可用。

　　使用攻击树（Attack Trees）来模拟威胁是最古老和应用最广泛的技术之一 ，由Bruce Schneider于1999年开发，最初作为自己的方法应用，此后与其他方法和框架结合使用。

　　攻击树本质上是以树的形式描述对系统的攻击的图表。树根是攻击的目标，叶子是实现该目标的方法。每个目标都表示为一个单独的树。因此，系统威胁分析产生一组攻击树。

　　在复杂系统的情况下，攻击树可以为每个组件而不是整个系统构建，构建攻击树后，可用于做出安全决策，查看系统是否容易受到攻击，并评估特定类型的攻击。

　　攻击树易于理解和采用，但只有在充分理解系统和安全问题时才有用。该方法假设分析师具有较高的网络安全专业知识，因此不提供评估子目标、攻击或风险的指南。

　　这种混合方法由协同应用的攻击树、STRIDE和CVSS方法组成。它是在 2016年4月在宾夕法尼亚州匹兹堡举行的 HotSoS会议上由 Bradley Potteiger、Goncalo Martins 和 Xenofon Koutsoukos推出的。作者旨在解决网络物理系统威胁建模的一些紧迫问题，这些系统的组件之间具有复杂的相互依赖关系。

　　定量威胁建模方法（Quantitative TMM）的第一步是为STRIDE的五个威胁类别构建组件攻击树。此活动显示了攻击类别和低级组件属性之间的依赖关系，之后，应用 CVSS 方法并计算树中组件的分数。

　　该方法的另一个目标是为各个组件生成攻击端口。这些攻击端口（实际上是组件攻击树的根节点）说明了可以将风险传递给连接组件的活动。评分有助于执行系统风险评估的过程。如果攻击端口依赖于高风险评分的组件根节点，则该攻击端口也有高风险评分，被执行的概率也很高，反之亦然。

　　威胁建模是分析应用程序安全性的一种结构化方法，通过识别威胁，定义防御或消极威胁控制措施的一个过程。

　　目的是为了更好地理解系统架构，为辨别威胁做准备。具体就是绘制系统架构图，包括标识子系统，信任边界和数据流等。

　　根据架构图以及功能需求描述，对系统进行数据流分析，绘制相应的数据流图，识别关键技术，信任边界及系统的入口等。

　　威胁分析方法有威胁列表、攻击树、STRIDE方法等，STRIDE 是从攻击者的角度，把威胁划分成 6 个类别，分别是 Spooling（仿冒）、Tampering(篡改)、Repudiation（抵赖）、Information Disclosure（信息泄露）、Dos(拒绝服务) 和 Elevation of privilege (权限提升)。这 6 类与信息安全三要素和信息安全基本的三个属性相关。随着国内外对个人隐私保护重视程度加大，如果业务涉及个人信息，也需要考虑对隐私数据的保护。

　　STRIDE威胁建模第一步是绘制数据流图，数据流图由外部实体、处理过程、数据存储、数据流组成。STRIDE 威胁建模的核心就是使用这四类元素绘制数据流图，然后分析每个元素可能面临的上述六类威胁，针对这些威胁制定消减方法。STRIDE 四类元素与六类威胁的对应关系见下图。

　　评估威胁的优先级，需要首先解决最重要的威胁。可以采用DREAD风险模型进行威胁风险评级。DREAD从潜在损害、可重复性、可利用性、受影响用户、可发现性5个方面进行评分。

　　一旦获得风险等级，就可以更新记录的威胁并添加发现的等级。威胁建模过程的输出包括应用程序体系结构的安全方面的文档以及威胁的列表，最终输出安全设计方案，项目团队基于安全设计方案进行系统功能设计和开发，减轻攻击风险。

　　从上面威胁建模过程可以看出，流程太重，过于繁琐，且对于人工投入要求较高，很难适应业务的敏捷快速迭发模式，在实际研发过程中很难落地。因此在实际使用中，我们对威胁建模过程进行了优化，将安全需求分析和架构设计过程结合，提出了基于场景化的轻量级威胁建模方法，主要步骤如下：

　　（1）问卷调研。目的是要了解系统的关键信息，为后面的攻击面分析及威胁建模做准备。调研问卷主要包括系统架构、使用场景、重要数据、部署方式等。其中系统架构关注统架构图、技术实现方案等，使用场景关注用户场景、用户群体、角色、访问方式等，数据关注是否有敏感数据，而部署关注部署架构及物理资产。

　　（4）安全设计方案。根据威胁分析结果，匹配安全需求标准库，输出进行威胁缓释需要实施的安全需求基线，制定最终的安全设计方案。

　　随着互联网和金融科技的发展，科技产业和证券产业逐渐融合，现在的证券应用越来越多地采用互联网技术和信息通信技术开展各种服务。在上述背景下，需要各种应用系统和软件来实现相关业务功能，广泛应用于证券行业的各大细分领域。

　　根据金融应用软件的部分共性特征和证券业应用部分独有特征，总结相关的应用场景。根据用户区分为对客和自有员工，对客场景又划分为业务场景、应用场景和部署场景，自有员工场景划分为办公场景和业务系统场景。

　　对客的业务场景主要由客户端、通信网络和服务器组成，客户端一般分为移动APP、PC exe和浏览器，用户通过互联网与服务器进行交互，实现注册、登陆、交易等下述功能场景。

　　新用户在使用系统前需要进行注册，应该支持多种方式的注册途径，例如手机号注册、用户名密码注册，用户注册时需要对其密码复杂度进行检查并在《用户注册条款》中告知用户妥善保管密码，避免使用生日等个人有关信息作为密码等。

　　关于第一次登录应该增加认证强度，推荐使用手机号+验证码登录，认证通过之后可以将当前设备认定为一个可信设备，后续登录可以适当使用指纹或人脸等简化登录流程。但如果其他设备进行登录、token超时等事件发生后，该设备应该重新发起短信验证码等高强度的认证方式。

　　用户开户现在分为非现场开户和现场开户两种方式，现场开户是在柜台直接办理开户业务，暂不涉及相关场景。非现场开户主要分见证开户和网上开户，网上开户又有以下几种场景：

　　根据《中国证券登记结算有限责任公司证券账户非现场开户实施细则》规定，网上视频见证方式（双向视频见证或单向视频见证）验证投资者的身份真实性及开户意愿真实性后，为投资者办理证券账户开立手续，确认本人身份无误。

　　证券公司信息系统原则上都应该做等级保护与备案工作，涉及交易的应用，交易用户数划分，超过50万人以上应定级为系统，不超过的应定级为二级系统，需要按照应该按照对应的等保标准来实现。

　　为了开拓市场，扩大影响力，开拓并巩固营销渠道，发展客户，增加客户总量，业务部门会开展很多的营销活动，例如赠送优惠券、交易折扣、注册有礼、排行榜、新人活动、老带新等，要控制相关的活动逻辑，提防业务风险。

　　客服系统包括在线客服沟通留痕系统、呼叫中心、智能客服系统等。在线客服沟通留痕系统主要是通过使用app或者网页和客户进行人工交流。呼叫中心是指客户部分常见问题的应答实现由机器“自动话务员”来应答和处理,以电话接入为主的呼叫响应中心，为客户提供各种电话响应服务。智能客服是指智能客服机器人通过融合客户画像数据信息，个性化地推荐产品或出示专业的咨询服务。会依据客户的提出问题全自动配对知识库系统，快速响应顾客。

　　自有员工业务场景包括OA办公系统（如邮件、会议预订、HR、流程审批等），移动办公、业务工作平台（业务人员通过业务终端访问，如CRM、业务运营平台等）、IT管理后台（如官网管理后台、AD等集权类系统等）等。

　　近几年证券行业持续面临愈发严峻的网络威胁形势，随着证券行业数字化转型，新技术与业务快速融合，证券行业所面临的网络威胁不断增多，数据泄露、系统入侵、业务欺诈、钓鱼攻击、撞库、DDoS攻击等网络安全问题层出不穷。根据调查，Web安全漏洞依旧是最主流的漏洞类型，证券行业漏洞主要有敏感信息泄露、未授权访问、SQL注入、越权、XSS、逻辑漏洞、弱口令等。

　　通过多年对证券行业相关系统安全威胁分析实践和优化，本文提出了一种基于客户(Client)-运营(Operation)-系统本身(System)的安全威胁分析方法，简称“COS安全威胁分析方法”。“COS安全威胁分析方法”的原理来自于“威胁不止来自于系统本身的脆弱性，更来源于人”，该分析方法结合证券行业业务的特殊性强调从客户-运营（包含运营人员）-系统本身三大视角来看待安全威胁。

　　证券行业相关系统的核心交互方可以概括为：客户（普通客户与机构客户）使用相关系统达成自己的财务目标，运营人员使用相关系统对产品和策略进行运营并与客户沟通、相关系统负责处理客户与运营人员的相关信息并反馈结果。

　　然而，业务交互的地方便是威胁发生的地方。如下图所示，恶意客户(黑客)以“外部人员”身份从外围发起攻击，恶意运营人员以“内部人员”身份从内部发起攻击。恶意客户和恶意运营人员通过利用系统安全设计缺陷以及代码缺陷谋取自己的利益。通常人们倾向于恶意攻击主要来自于“外部人员”，但是调查研究表明重大的数据泄露和安全事件更多的来自于“内部人员”。

　　“COS安全威胁分析方法”将“外部人员”威胁与“内部人员”威胁放在同等的位置，注重从“外部人员C”与“内部人员O”的非法利益层面出发来看待威胁，再结合系统本身层面可能的漏洞，对威胁进行联合评估，并要求从系统层面对“外部人员”威胁与“内部人员”威胁进行严格的审视。

　　明确客户-运营（包含运营人员）-系统本身这三大要素和视角后，安全工程师可以非常方便的与架构师及相关开发人员进行沟通，设计对应的安全需求(功能)和缓解措施。

　　证券行业典型业务场景有客户使用开户系统进行注册开户、使用app客户端进行相关买卖交易、资金结算，运营人员通过运营管理平台进行相关管理操作（如营销和相关产品上下架）及智能客服系统与客户进行线上联动交互等。

　　证券开户业务涉及到账号注册、身份认证、资料上传、视频认证、密码找回等多个环节，根据“COS安全威胁分析方法”，识别的安全威胁如下：

　　证券公司很多产品均来自外购而非自研，不同产品的运营平台框架和结构不一样，面临着供应链相关漏洞的风险，根据数据统计，运营平台对内部员工权限分离通常做的并不彻底，某些关键操作没有进行多人审批，并且对操作记录未留痕审计，容易出现“内鬼捣乱，找不到鬼”的现象，且攻击者可以通过运营人员经常访问的网站注入相关恶意脚本和信息，进行钓鱼，获取运营管理平台的口令和高级权限。运营管理平台所面临的安全威胁具体如下：

　　证券行业因其特殊的“金融属性”，客户和运营人员更容易遭受黑客攻击，客户和运营人员也更容易“监守自盗”，本文结合证券行业攻击特征，通过“COS安全威胁分析方法”总结了一套“COS安全威胁库”，该威胁库将证券行业多个系统所面临的威胁进行总结，将威胁分为三个领域Client、Operation、System。Client和Operation从客户和运营(运营人员)角度侧重描述业务利益相关的威胁，System侧重从系统本身的设计和编码角度描述相关的安全威胁。

　　确定了业务场景及面临的安全威胁，则需要进行风险缓释，提供相应的安全需求及安全解决方案，在系统建设过程中通过设计保证安全（Secure By Design）。通过构建证券行业安全需求库，实现安全威胁库中的风险都有对应的安全需求及针对性解决方案。

　　证券行业信息系统建设主要特征有：内部开发与外部购置并存，对于外部购置的信息系统，很难有效控制交付产品或服务的内在安全质量；内部开发团队众多，但并没有将基础的安全功能（包括：用户管理 、认证、权限等）进行剥离和专业化定制，因此，各个开发团队对安全需求的不同理解和实现，将直接影响到最终系统的安全质量；信息系统的开发过程和进度主要围绕业务功能和上线目标展开，质量等软性要求的关注度并不够，对于安全质量的内在重视程度欠缺；证券公司IT人员中，专业信息安全人员比例不足，面对每年众多的新建、改建项目，无法一一跟踪具体的安全建设过程；法律、法规，行业监管相关的管理办法、技术标准、检查底稿众多，层出不穷，细粒度不均，有些甚至相互冲突，另一方面，证券公司面临的监管机构众多，国家的、地方的、行业内的、行业外的，这些机构的各项检查和通报实质上已经成为证券公司信息系统风险的主要评价源。

　　安全需求库主要目标应该是提供项目初始阶段，安全考虑的依据和范围，降低安全需求活动执行的启动难度，提高效率；在满足合规监管和公认的最佳实践基础上，各证券公司根据自身特点，进一步补充安全政策和自身实践。

　　安全需求描述了为实现系统安全属性所需要满足的功能性和非功能性要求。安全需求可以具有不同的抽象层次，最高层一般反映的是安全目标，如：“系统应对所有敏感数据保密”，从开发和实现角度来看，对于系统架构师或开发团队而言，往往还需要更加具体的需求描述以规定要做什么，做成什么样甚至怎么做，来保障系统及其数据的安全，即提供或推荐进一步的最佳实践或解决方案。

　　安全需求库的来源主要有感知到的终端用户需求、法律法规、监管、按优先级排序过的风险场景、最佳实践与标准等。

　　安全需求库，需要覆盖并满足国家层面和监管机构对证券公司信息系统的合法合规、监管要求，同时结合安全行业公认的安全实践，以及公司自身对信息资产保护的目标和具体需求，安全需求库同时应该包括有推荐的解决方案或最佳实现方法，向项目开发团队提供明确的实施指导。安全需求库以一定的方式分层构建，可以随安全风险水平和IT开发成熟度的提升而支持进一步扩展和更新。

　　华泰根据多年实践，将安全需求划分为14大类分类，包括合法合规、用户管理，授权、会话管理、日志与审计、错误与例外处理、通信安全、数据安全、结构安全、软件与组件安全、OWASP TOP 10风险防范、其他常见风险防范、移动安全、监管安全需求，并根据新技术发展持续进行补充。大类中的每一条安全需求，都会有细分类、来源，需求内容（基本要求、推荐做法、注意事项、正反例），安全目标、适用条件、需求来源等描述。

　　为了提高效率，自主研发了轻量级威胁建模赋能平台，进行自动化轻量级威胁建模。轻量级威胁建模赋能平台旨在帮助项目经理了解并实施从项目规划开发到上线运行各个阶段的安全及合规需求。项目经理通过自助输入用户业务场景、架构部署方式及关键技术选型等信息，平台自动化生成所需要完成的安全及合规需求，并提供对应的安全解决方案。

　　平台功能包括自定义业务场景问卷（见图16）、安全需求库管理（见图17）、基于业务场景威胁分析、自动化匹配安全需求基线、最佳实践及安全需求闭环跟踪（见图18）等。

　　华泰证券采用本课题的轻量级威胁建模方法，在日常项目建设过程中，对数百个应用系统进行了安全需求分析及设计，安全缺陷在软件开发早期阶段被发现并解决，实现了安全左移，极大的降低了漏洞修复成本。同时，自主研发了轻量级威胁建模平台，实现自助化及自动化的威胁建模，降低了人力投入，提升了威胁建模效率。

　　行业机构可以参考本课题提出的轻量级威胁建模方及实践，逐步进行自身轻量级威胁建模实践，大幅降低学习和应用成本，提升行业整体的软件安全成熟度水平。