江旺 华泰证券信息安全中心负责人；庄飞 华泰证券信息安全中心应用安全团队经理
摘要：当前金融行业面临前所未有的威胁挑战，而大量的应用层安全漏洞暴露出安全开发实践方面的欠缺。为了降低漏洞修复成本，安全“左移”是一个趋势。本文将从证券机构金融APP的实际案例入手，讲解如何通过轻量级威胁建模，进行应用安全架构设计，系统性地降低应用系统安全风险。
关键词：安全架构设计、轻量级威胁建模、自动化威胁建模
根据Freebuf《2020-2021金融行业网络安全研究报告》显示，随着越来越多的金融机构进行数字化转型，信息化、网络化已成为现代金融行业的重要特征。与此同时，金融行业的网络安全风险不断累积，金融安全防护面临前所未有的威胁挑战。Web安全漏洞依旧是最主流的漏洞类型，热门漏洞有XSS、SQL注入、敏感信息泄露、未授权访问、弱口令、远程代码执行、任意文件读取、逻辑漏洞等，暴露出应用系统在安全开发实践方面的欠缺。应用系统上线后漏洞修复往往要耗费较长时间和较高的成本。
在实战攻防演练中，也经常暴露出很多应用层问题，如高危框架或中间件、第三方开源组件漏洞、安全配置错误、设计不当、API未授权访问等业务逻辑问题、敏感数据保护不足等。
为了尽早发现安全风险，降低漏洞修复成本，安全左移是一个趋势。在项目早期阶段进行安全架构设计，是一个系统性解决安全风险的有效方法。本文将从金融APP的实际案例入手，探讨如何通过轻量级威胁建模进行应用安全架构设计。
Gartner对安全架构的定义是：安全架构是计划和设计组织的、概念的、逻辑的、物理的组件的规程和相关过程，这些组件以一致的方式进行交互，并与业务需求相适应，以达到和维护一种安全相关风险可被管理的状态。
ISF报告中，对安全架构的定义是：安全架构是一组表示形式，描述了环境中安全组件的功能，结构和相互关系。安全组件可以根据安全架构的类型而有所不同，但通常包括安全控制措施、安全服务（例如身份验证、访问控制等）和安全产品（例如防火墙、入侵检测等）。
安全人员一直面临着挑战：如何将业务问题、威胁、IT与构建的防御体系联系起来？安全架构可以解决这类问题。安全架构提供了一种结构化的方法，向IT服务、应用程序和平台添加安全控制措施，系统性地解决安全风险问题。
在安全架构的开发过程中，通常会产生许多表示形式。随着业务安全需求转换为安全控制措施，表示形式变得更加具体，形成了分层安全架构模型。
如何来设计安全架构，有方法论（Methodology）或者框架（Framework）作为参考。框架是一套系统的控制点和实践的组合，关于“what”的条目组合，而方法论是一系列从起点到目标的实施步骤，关于“how”的指南。
安全架构方法论的一个典型例子是SABSA,它建立在Zachman企业架构方法论的基础上，采用类似的结构，称为SABSA矩阵,用于帮助描述组成安全架构的视图和组件。还有其他一些方法论，比如Open Group的OSA和O-ESA。
NIST CSF是一个通用框架，提供了一种方法为组织定义逻辑安全架构，它让用户能够识别业务活动的网络安全风险，然后构建一个控制能力概要。
另一个方法论OSA提供了很多类架构模式、威胁目录以及控制目录，这个社区已经很久没有更新了，但还是具有一定的参考价值。
在安全架构设计中，有个很关键地方就是要遵循安全设计原则。安全设计原则，是在安全业界实践中已被证明是成功的抽象概念的集合，是无数前辈经验的总结。它告诉我们安全设计的正确做法以及为什么这么做。应用系统的设计人员应遵循这些安全设计基本原则进行威胁分析和安全方案设计，避免由于设计不当引入的安全风险，提升应用系统的安全性。
当今安全设计经典理论中，最为经典、被引用最多的是由MIT的Saltzer教授在1975年首先提出的8大安全设计基本原则，被安全业界奉为“经典安全原则”。经过业界多年的发展和总结，在原有8大经典设计原则的基础上，又发展引申出其他一些安全原则，例如“纵深防御”、“不要轻信”、“保护薄弱环节”、“提升隐私”原则等。
应当指出的是，并非所有的安全设计原则都需要完全在一个系统中实现。有些安全设计原则本身就是相互冲突的，需要做出权衡。
安全架构设计方法，主要是通过攻击面分析和威胁建模手段识别威胁、建立风险消减措施，最终形成安全设计方案。
攻击面是指应用软件任何可被人或其他程序访问的部分，而攻击面分析的目的是为了减少应用和数据暴露在不可信用户面前的数量。攻击面分析的核心是识别访问入口及信任边界。访问入口就是数据流入流出的入口点，如身份认证入口点、管理页面、传输接口等；信任边界有网络边界，如互联网、DMZ、核心网、办公网，也有应用或服务边界，其他还有主机边界等。攻击面分析还需要确定应用程序中的有价值的数据（例如机密、敏感、合规的）。
威胁建模是分析应用程序安全性的一种结构化方法，通过识别威胁，定义防御或消极威胁控制措施的一个过程。威胁建模主要有6个步骤：
1、识别资产。确定必须要保护的有价值的资产，如敏感数据、隐私信息等。
2、创建架构概述。目的是为了更好的理解系统架构，为辨别威胁做准备。具体就是绘制系统架构图，包括标识子系统，信任边界和数据流等。
3、分解应用程序。根据架构图以及功能需求描述，对系统进行数据流分析，绘制相应的数据流图，识别关键技术，信任边界及系统的入口等。
4、威胁识别。威胁分析方法有威胁列表、攻击树、STRIDE方法等。比较常用的是STRIDE，STRIDE是从攻击者的角度，把威胁划分成6个类别，分别是Spooling（仿冒）、Tampering(篡改)、Repudiation（抵赖）、Information Disclosure（信息泄露）、Dos(拒绝服务)和Elevation of privilege(权限提升)。这6类与信息安全三要素和信息安全基本的三个属性相关。随着国内外对个人隐私保护重视程度加大，如果业务涉及个人信息，也需要考虑对隐私数据的保护。
5、记录威胁。根据识别的威胁分析可以实施的缓解措施并记录下来。
6、评估威胁。评估威胁的优先级，需要先解决最重要的威胁。可以采用DREAD风险模型进行威胁风险评级。DREAD从潜在损害、可重复性、可利用性、受影响用户、可发现性5个方面进行评分。一旦获得风险等级，就可以更新记录的威胁并添加发现的等级。
威胁建模的输出包括应用程序体系架构安全方面的文档以及威胁的列表，最终由安全团队输出安全设计方案，开发人员基于安全设计方案进行系统功能设计和开发，通过设计安全（security by design）降低安全风险。
从上面威胁建模过程可以看出，流程太重，过于繁琐，且对于人工投入要求较高，很难适应业务的敏捷快速迭代开发模式。因此在实际使用中，我们对威胁建模过程进行了优化，将安全需求分析和架构设计过程结合，设计了轻量级威胁建模，主要包括攻击面分析、安全威胁库及安全需求库。
安全建设的目标，就是保护信息资产，实现信息安全三要素CIA，机密性（只有授权用户可以获取信息）、完整性（信息在输入和传输的过程中，不被非法授权修改和破坏，保证数据的一致性）和可用性（保证合法用户对信息和资源的使用不会被不正当地拒绝）。下面以证券机构某金融APP实际案例，讲解如何通过轻量级威胁建模，进行安全架构设计。
该产品是一款投行类一体化服务平台，支持移动APP客户端及Web页面，目标客户既有企业内部人员，也有外部客户，以及第三方机构。
对项目组进行问卷调研，目的是要了解系统的关键信息，为后面的攻击面分析及威胁建模做准备。
调研问卷主要包括系统架构、使用场景、重要数据、部署方式等。其中系统架构关注技术实现方案、系统架构等；使用场景关注用户场景、用户群体、角色、访问方式等；数据关注是否有敏感数据等；而部署方式关注部署架构、资产清单等。
根据系统架构图，可以了解应用的基本结构。前端有APP，Web UI，后端采用微服务架构，且应用和第三方服务有交互；使用场景，既有外部客户，也有内部用户，暴露的接口有web页面，也有Restful API；存在客户敏感数据。从应用的部署架构，可以看到应用分布区域有互联网、DMZ、核心网及办公网。
根据调研问卷，可以大概了解应用系统的相关信息。本文的安全架构设计，关注的是通用安全风险，对于业务内部逻辑风险不做展开。
首先讲一下本机构的网络区域划分：有互联网接入区DMZ、核心生产网、办公网、开发测试网、业务网，其他还有托管机房区、外联业务区、客户接入区、AWS等。
下面进行攻击面分析。基于部署架构图，简单画了数据流图。
可以看出，外部实体，有通过互联网APP及Web访问的外部客户，也有业务人员，还有IT运维人员，以及日志平台及第三方系统。
这么多的攻击面，如何识别威胁及消减风险，我们主要靠安全专家经验、长期积累而形成的安全威胁库。我们并没有严格的区分安全需求及威胁建模，这个过程我们称之为安全需求分析与架构设计，也就是轻量级威胁建模。根据业务场景，与安全威胁库中威胁模式匹配，输出安全解决方案。
针对本案例的金融APP的安全设计，选择部分进行详细描述。
1）结构安全。首先是系统分层，系统应该采用分层部署的结构，不同的组件按功能和重要程度分布于不同的网络区域中。
生产环境中，需要与外网（互联网）发生通信的主机，一般位于DMZ层，禁用在生产网的核心层与外网直接通信。应用部署在核心网，需要在DMZ部署接入层服务，禁止直接DMZ区部署nginx反向代理接入。从安全风险角度，Web服务部署于DMZ区，在DMZ区进行http协议卸载、参数过滤及协议转换，DMZ到核心网使用tcp协议，这样，可以防止攻击payload直接打到核心网。运营管理后台，业务运营人员采用专用的业务终端通过业务网进行访问。IT人员通过堡垒机进行系统运维。后台管理页面禁止直接开放到办公网访问（因为办公网可以访问互联网，员工存在被网络钓鱼导致机器被远控风险，从而通过后台管理页面漏洞侵入核心网）。
系统使用的第三方组件如tomcat，应采用无安全漏洞版本。部署系统所采用的软件也应该满足安全性，版权合法且无安全漏洞。
a)APP代码保护。基于目前市面上提供了很多或开源或商业的逆向分析工具，如apktool，dex2jar，baksmali等，因此攻击者很容易就可以获得应用的反编译代码，几乎就是应用源代码。在此基础上，进一步分析应用中存在的安全漏洞以及业务逻辑，并进而攻击服务端。为了提高逆向分析的门槛，可以进行代码混淆、dex加壳、so加壳等方式对代码进行保护。
b)APP运行时保护。对移动端应用的逆向分析还有动态调试。动态调试分为Java层和native层动态调试，通过动态调试，跟踪应用运行行为，猜测业务逻辑；同时，通过动态调试还可以伪造或篡改请求/响应包，从而攻击服务器端。可以在代码中加入动态调试检测来进行反调试，如调试器进程名检测、ptrace检测、xposed hook框架检测等。
可以采用加固工具对Android APP进行加固保护，防止恶意破解、反编译、二次打包等。国内有很多提供APP加固服务厂商，需要注意的是，加固会造成性能的损失，严重情况下可能造成应用崩溃，因此需要做好兼容性和健壮性测试。
c)APP第三方代码安全。移动应用开发过程中，出于功能需求等原因，开发人员不可避免会集成一些其他第三方提供的代码，如SDK。这些第三方代码未经测试和评估就直接嵌入到应用中直接使用，容易出现不可预料的后果。一方面是第三方代码的安全性未经测试，可能存在安全漏洞被攻击者利用，从而威胁整个应用的正常使用。另一方面，第三方代码额外实现了冗余功能或者申请多余的特权，可能造成用户隐私信息泄露，或者一系列恶意行为。
对于此类威胁，安全设计方案是：集成第三方代码时，开发人员应尽可能了解第三方代码的功能，以及尽可能保证第三方代码的安全性。需要在下载、集成、评估、更新升级四个阶段都注意安全，实现必要的安全措施：从官网安全下载和使用；对代码进行漏洞扫描，漏洞包括有常见Android应用漏洞，例如组件暴露、webview漏洞等；代码审计，检查第三方代码是否实现多余功能或申请过多权限，审计是否有恶意代码、敏感数据收集及传输等；升级和更新，一方面是漏洞的应急响应，对于已公布的安全漏洞有及时的响应；另一方面，更新时候需要重新检测第三方代码新版本的安全性。
d)APP端业务安全。为了防止APP用户恶意注册及薅羊毛等恶意行为，可以在APP中加入设备指纹，进行数据埋点等，将APP数据接入业务风控平台，进行业务反欺诈。
3）Web安全。对于Web安全，关注常见的OWASP TOP 10漏洞，如注入、身份认证、敏感信息泄露、安全配置错误等。常见的防御措施有认证、授权、加密、审计、输入验证等。
Restful API以URI方式对外提供数据服务或功能服务。外部用户多数情况下是程序或系统。提供的数据服务或功能服务多数情况下，是非公开的，即需要对HTTP请求来源和身份做识别与认证，再经过授权决策（访问控制）后，提供相应的数据或执行功能。
-
互联网上暴露Restful API(或HTTP服务接口）时，应该加密（如HTTPS）；
-
采用appid、appkey或jwt等方式，来标识访问者身份；
-
非公开Restful API服务，必须在每个端点上做认证和访问控制；
-
-
对接口调用进行流量控制，控制规则包括最大允许应用程序接口调用并发数等，控制措施包括告警、暂停、拒绝等。
其他还要考虑的领域还有数据安全、个人隐私评估、大数据安全等，由于篇幅关系，就不做展开了。对所有攻击面进行威胁库匹配，最终形成的就是该产品完整的安全解决方案。在实际实施过程中，业务也会在实现安全功能的投入和安全风险间进行权衡，并不一定会实现所有的安全设计方案。
如今，越来越多的企业开始采用DevOps开发模式，实现价值的快速交付，也催生出来DevSecOps理念，本机构也很早就探索并落地DevSecOps实践。在DevSecOps中，如何实现安全架构设计的快速交付？
通过自研三叉戟SDL全流程赋能平台，自动化实现基于场景的轻量级威胁建模。
实现思路为项目组自主进行安全调查问卷的填写，平台基于调查问卷的业务场景，匹配安全威胁库，关联安全需求库，自动化输出安全设计方案。安全人员负责安全威胁库及安全需求库等的完善。
未来，可以借助人工智能及NLP等技术，实现自适应的智能化威胁建模。
本文介绍了如何进行安全架构设计，以及轻量级威胁建模实践，通过安全左移，从源头管控安全风险，降低漏洞修复成本。行业机构可以参考本文的实践，进行自身的安全架构设计探索和落地。
—————————————————————————————————————
原文始发于微信公众号（君哥的体历）：华泰证券：证券行业应用安全架构设计实践
