实录 | kEvin1986：浅谈风控安全

【分享题目】浅谈风控安全

【分享人简介】kEvin1986, 前搜狐网络安全负责人，前脉脉网络安全负责人，擅长攻防对抗，黑产打击和研究。

【分享形式】群内分享，图文穿插形式。嘉宾将会在「金融业企业安全建设实践群」和「企业安全建设实践群」2个微信群里，就“浅谈风控安全”进行个人经验的分享。

【分享内容梗概】

目录：

1、风控安全和传统安全的区别

2、风控安全中常见的风险场景

3、风控风险的威胁建模

4、已存在的风险排查和落地

5、风控中的攻防对抗技巧和经验

【分享时间】5月20日晚上7点30分开始，持续60分钟和20分钟的QA环节

-------------------------------------------------------------

以下为实录：

很高兴应聂君邀请来做一个关于风控的分享，主要是讲讲个人经验，有不足的地方希望大家海涵：）之前做了点准备，本来是想上来就比较正式地聊聊风控安全和传统的安全建设的区别，不过我打算还是先直接就进到更干点话题吧。

群里也有不少做风控相关的同学，我们先来讲讲风控这个事情都可能发生在哪些场景。

一、常见的风险场景

大部分时候当我们说起风控，都可能是在讲某个业务逻辑上出现的风险。近些年，这些风险可能会比较集中地表现在如下关键词当中：薅羊毛、爬虫、黑卡、养号、假流量、电信诈骗、三方数据泄漏等。

这些名词经常会给人造成一些误解，认为这些名词都更偏向于运营和产品层面，是“业务安全”的范畴。但是当在业务本身更注重盈利和有效转化的情况下，对抗这些风险所带来的危害就更多地落在了技术层面上。

事实上在对抗这些风险时，我们需要先对这些名词做一些解释，并将其拆解成一系列技术动作，看看这些技术动作都可能出现在哪些地方：

图片点击可放大

我们可以看到在拆解这些风险可能产生的动作时，经常会看到“批量产生特定行为”这个标签。先特别说一下，“批量”只是风险利用投入的成本的一种换算，在一些技术漏洞、产品漏洞存在的情况下，存在着低成本换算的逻辑，比如某个漏洞可以直接操作转账或结算、或直接更改价格或重要指标数据、拖库、黑客入侵、内鬼勾结之类的都可算作降低利用成本的方式。在对以上风险进行规避前，说太多的控制实际上是杯水车薪。当然关于上面这些，也都是各位大佬擅长的地方，我就不在这里班门弄斧了。

话题转回来，我们看到上边的一些tag都在描述收益，可以知晓风控在更多的时候是在一种预期收益行为下对抗非预期损失的工作。这种时候更多是在业务实现收益逻辑时，没有去了解整体环境导致的，比如说某个业务只看重了短期ROI，但是忽略了该ROI对其他关联业务的收益造成损失，这种收益和损失的冲突实际上不可避免，做好风控这件事情实际上是落地多种平衡策略。

提炼一下场景:

1. 权益场景。体现在账号、特定受益群体按照“游戏规则”产生和获取收益的地方，需要更关注于身份伪造、模拟特定行为这些问题，同时在业务中更多的控制利益向下游多次转化的问题。

2. 信息泄漏场景。体现在规模化获取和制造信息，多个不同渠道的信息关联问题上。则更需要关注数据安全合规、数据输出标准化流程化、量化异常、数据蓝图暴露面和上下游数据价值问题。

3. 身份控制场景。主要体现在账号权益、身份自证、上下游信任链问题上，通常会关注于如何鉴别主体的主观特性，权益是否可以被交易，身份历史行为和关联行为是否过分有目的性，身份画像描述是否准确问题。

而事实上，风险往往不是出现在某一个单一场景上，更多的时候是以复杂地方式出现的，这个时候我们就需要对某个场景上的某些功能和逻辑进行风险的威胁建模。

二、风控风险的威胁建模&对已存在的风险进行排查和落地

威胁建模的模型很多，在不同的行业也有不同的方式，我这里有几个例子，可以使用stride方式简单的进行建模，从面上看清风险大盘。

下面我通过一个例子来讲一讲如何对一个系统进行风险建模并且应急和落地：

我曾就职过的某家公司举办了一个活动，其目的是在合理合法的方式下邀请用户主动填写一些自身的信息作为后续项目冷启动的资料，为了提高用户参与的积极性，每当用户填写了一部分信息之后，就赠与用户一部分权益，这些权益累加之后可以去另一个业务线管辖的业务中兑换实体具有价值的物品（当然也包含部分线上实体物品），物品将会以默认物流的方式在一个月内进行递送。这个活动上线时并没有知会任何其他部门，经费来自于其部门财年的自然预算。

后果可想而知，在活动进行了3天后，其关联业务部门向采购部门求救，称某活动快把库存中某特定商品耗尽了，需求给出对策，采购部门认为其中存在风险，向安全部门发起协查请求。先不管后续处理和逻辑，让我们来看看这个活动是否可以通过STRIDE模型建立一个风险指标：

图片点击可放大

题外话，我们可以看到建模逻辑中包含了一些向内的指标，事实上是用于约束内部舞弊的。在实际风险分析的过程中，我们不能只看外部可能导致的风险，很多时候内部人员实际是知晓风险的，甚至还存在舞弊的可能性。如果不向内约束，在后续的风险控制过程中就没有很好的办法做到平衡了，所以对于内部人员尤其需要加强防范。

综合在建模过程中，需要严格围绕几个层面去看：

1. 收益双方的利益是否符合预期；

2. 每个链路上都需要有相关的审计和应急机制；

3. 需要明示最“核心”的风险指标，并根据其扩散上下游的风险点，寻找到风险最高的链路；

4. 在建模时不需要考虑业务营收的问题，因为这不是最终结果，实际参与安全规划的部门需要明示风险，并在后续和业务部门一起核对目标时，对冲突的逻辑进行权衡。

根据以上模型，再和业务核对，就发现了以下一条“性价比”最高的路径：

1. 公司内上亿的账号均可参与这个活动，且无法很好的确定信息的准确性； 

2. 仅通过账号来限制，多个账号的最终收益方可以是某个自然人和某个团体。；

3. 和各关联部门没有形成联动和预警，导致兑换价格和参与收益成本不均衡。

最终的线路其实很简单，有专门的养号群体通过长期低成本获取的账号参与活动，使用自动化工具填写信息并获得活动内的大量权益，同时在结算链路上做了对抗审计的策略，将某物品通过分包模式派送到全国各地，最后收敛到线上。其中10%左右的账号收获了75%左右的权益，利差极大，导致活动失败。

以上仅是我参与到众多个风控事故的其中一个，其他还有很多模式的风险，可以在后续的交流中和大家分享。

还是跟着上面的案例进行分析，我通过威胁建模和各种日志进行了分析，同时也分析了参与活动的用户画像构成，发现了如下现象:

1. 参与活动的账号有存在行为共性，表现在大量账号是在历史上的某个时间段中创建，创建账号的入口业务和发起活动的业务关联性不强。用户在历史中提交的资料和参与分派的地理位置存在较大符合，日志中体现部分逻辑冲突，如IP，UA，特殊Header 均存在异常；

2. 该活动的内容可以在"xxxxxx8.com和bbs.xxx.la"网站上找到，以上两个网站主要提供各类减价信息和工具。其中在xxxxx8.com上发布的内容为公司内部运营人员所为，目的是为了追求活动在短期内起量；

3. 业务中出现了漏洞，重复、反复提交部分信息会重复派发增益；

4. 实时审计并未对可能产生的风险进行自动化标注。

以此，确定了多条风险：

1. 公司业务所控制的账号中，可能存在极大量的未明身份账号，且生产账号成本很低；

2. 活动的制作并没有经过SDL流程导致漏洞被利用，雪上加霜；

3. 活动发布选择的受众群体并非目标受众，可能存在舞弊问题；

4. 控制流程的缺失导致短期止血只能是中断活动，后续可能带来投诉、PR风险等。

在此整个风控事件分析完毕。很多细节因为保密的关系就不再赘述了，接下来我们聊聊如何避免这样的问题。

由于活动确实是业务后续发展需要，且需要避免贸然中止带来的风险，在安全部门和审计部门提出了整改要求，这里列举其中可以讲且后续形成机制的事情：

1. 账号系统作为核心权益分配的系统，提供了更多的校验和控制逻辑，并在活动运营中台强制布置了筛选机制。同时引入第三方如手机号信誉库、行为模式，对用户在账号层面进行打标，丰富画像逻辑；

2. 安全部门和CDN部门联动加强了WAF逻辑，制作了一套可编程的WAF框架接入活动中台，细粒度“实时”控制到每个API和子API，实现了业务层的AOP逻辑。同时和大数据部门完成了更细粒度的流量检测逻辑，将存在风险的逻辑实时打标给账号系统。同时要求每个活动在发布前必须引入应急控制机制，填写风险评估表，预测风险剖面。平台提供默认的应急SOAR蓝图和相应工具；

3. 安全部门针对特定的黑灰产渠道建立监测能力，可实时预警黑灰产风险，并联合相关职能部门进行有效打击。同时研究不同行业中已经产生的黑灰产链条，将其模式抽象后巡检当前所有的业务，对问题明显的进行整改；

4. 法务参与每个活动逻辑的协议、授权文案制作，为可能出现的应急风险创造法律解释空间，避免出现黑产恶意投诉、恶意诽谤的问题；

5. 成立了一个风控虚拟部门，抽调各关联部门的主要人员成为风险应急人；

6. 将有嫌疑的员工调离岗位并由内审进行审查。

至此，活动于关停三个月后整改上线，未出现异常，于一个月后下线关闭。这是一个很多年前的薅羊毛案例，但实际上归类风险，当前互联网依然存在着大量的雷同问题。当然，拥有和建立各种工具来对抗风险是技术可部分解决的事情，还有很多的问题不一定是技术原因，需要多个部门去协同。而此类薅羊毛、养号、内鬼问题在这些年内也出现异化，更专业，更团队，更产业，也需要持续的关注。

三、风控中的攻防对抗技巧和经验

最后再说一说风险对抗的策略。

在很多时候，有些风险是需要长期对抗的，比如业务原因必须披露某些数据，当数据在某维度价值较高，就一定会引入数据被爬虫的风险。在现实中和很多企业和做风控的朋友闲聊中，发现业务对爬虫止损的要求高于自身业务的要求，甚至有要求安全必须在xx毫秒内完成止损这种要求。这并不是说没有道理，但是忽略了一点，当业务不再进行有效的安全迭代时，相对于风险的价值依然存在，不正确的止血会带来对抗的升级，此时就必须去思考安全是否有足够的成本和风险利用去对抗。目前存在三种主流的对抗模式：

1. 仅线上止血：通过WAF、流量识别等方式尽可能快速的完成风险分析、制作策略发布、上线、 观察止血等几个动作。优点是快速，风险产生的损失最小。但在此时，攻击者往往会很快的摸出策略模型，更新利用的方式，久而久之，特征模型就会很模糊，对抗的成本就会变的很高。

2. 秋后算帐：对风险进行阶段时间的接受，长期观察风险维度和利用特征，在一定的环节和特定的逻辑下同时引入多个策略来阻碍攻击者的利用。此时攻击者可能会尝试多个不同的方式来猜测策略模型，但很难一次性完全命中。审计方就可以利用此类测试过程的数据进行溯源、打击、 预判新策略。当然弊端也是显而易见的，需要在一定时间内对风险造成的损失进行接受，部分高转化的逻辑风险并不一定适用此方式。

3. 将风险转化成收益：这个场景并不太多见，有一部分还涉及到法律问题，我就不在这里赘述了。其原理简单理解就是将攻击者的流量和带来的信息增值，在其他方面转售产生新的收益。

四、应聂君要求我再说说爬虫

爬虫在风险面上更趋向于数据安全方面，很多时候是数据在流动和融合时产生的风险。比如说一个业务会向互联网最终暴露某些数据，那最终的数据如果被抽象出来，是很难去跟踪数据去向的，而数据实际上在业务中的价值也很难衡量，很多企业在面对爬虫的时候，会出现不知道爬虫在哪儿，爬虫怎么根治，怎么溯源等问题，其实在和爬虫的对抗的时候，需要思考一些权益衡量点：

1. 数据输出场景是否合法合规？

2. 单份数据的价值有多少，输出后和市场上其他的数据融合可能会在哪些方式增值？

3. 数据获取的方式是否可能存在枚举的可能性？

4. 数据是否可以从推荐、各种列表中被聚合？

5. 是否在输出数据的时候，对请求来源进行标记？

6. 数据向哪些我能控制且别人也能控制的场景输出？

7. 一次正常的数据输出是否带来有价值的数据输入？

首先我们定义一个爬虫的最基本模式：

1. 要抓取的数据要有足够价值，可以是直接输出的价值，也可能是融合后的价值；

2. 要有效率和稳定性，这个可以和价值去换算收益比；

3. 要拟真，用于对抗反爬虫逻辑，往往他们会使用一个模拟设备，或者模拟一个真实环境进行；

根据上面这个基本模式，我们大致能发现，爬虫虽然是一种人机交互的识别对抗，但更多的价值体现在成本和收益对抗上，那如果从另一个角度去对抗，效果可以更好。我简单的说几个我曾经用过的效果比较好的对抗方式：

1. 对抗拟真和效率。很多基于API或者对目标具有很强针对性的爬虫都会有共性，在向一个API请求的时候，都只会去访问少量接口或页面，对抗这类的爬虫，我们在检出的时候，可以根据一个请求的环境特征，比如同时会访问页面、是否有首次访问的标记，app上的哪些数据口，以此建立一个模型，但凡和模型具有较大出入的，就基本可以确定是非人访问行为，爬虫要去对抗这种防御，要在拟真和效率上做出权衡，而防御这块，只要做上标记再对抗即可。

2. 利用一些请求工具的特性进行防御。比如IOS在对Cookie的Expires处理和安卓的各种WebView是不同的，面对伪装的UA，这种方式可以很好的确定攻击者是否刻意更换了请求特征。当然还有很多其他的特性，比如js和一些请求工具自带的信息。早些年的fingerprint里就具备很多这样的特征，部分可以参考。这种对抗拟真的方式投入比较大，可以做成框架性质去使用。

3. 过分的拟真。一个IP或者一个UA或者一些请求特征的聚合维度上，如果出现了大量的请求变化（指代和正常模型出入有区别），即可认为这个请求必然出现了非人行为，这个可以作为发现异常和风险的引子去做。

4. 设备指纹聚合：设备指纹并不是一个用于对抗爬虫的工具，但是它具备了对一个设备生命周期的管理特征。当很多爬虫去对抗设备指纹时，往往更追求一个真实的环境，这时就可以根据设备指纹去找到爬虫在时间上下文中的目标共性。这种对抗主要体现在效率的对抗上，爬虫如果没有注意，往往会使用单设备指纹，或者拟真了无效的设备指纹，这样就可以做到人机识别的检测。

5. 验证码虽然很常见，但是它的作用不是阻止爬虫，而是降低爬虫的效率。

在这种情况下，反爬虫的目标实际上是在做策略加固，用一种上帝视角去看，这样可以更直观的反应业务本身可能存在的信息泄露敞口面，还有风险，甚至还可以看到数据的基本价值和市场衡量，再依此做更向内的风险治理。

爬虫这块能说的还有很多，篇幅原因以后我们有机会继续探讨：）

总的来说，风控是一门平衡风险和收益的工作，单单是一个部门，一个企业其实很难真的做到完备的预测风险，是一门很深的学问，有问题大家可以随时交流。

---------------------------------------------

问答环节：

Q1：大佬，对于过分的拟真这种虽然能发现，但是在没办法改变数据的情况下如何防御呢？

A：实际上在对抗的时候，我们要看转化逻辑。比如爬虫过分拟真这个事情，在观察中很容易发现，但是需要考虑它在抓取什么样的数据，它的目标是什么，从规模和特征看是否会长期对抗下去，是否需要尽快止血。考虑到不同的可能性，假设没有办法直接在业务中控制，那么我们就要从整个链路的中间环节看是否可以积极介入，这里比如可以用AOP的方式，从整个数据链路，权益链路上去看，也可以从权益能力上去看，比如封号，封禁多个特征之类。甚至更多的时候，数据价值更高的情况，需要看自身的损失比来决定要采取的动作，觉得是否要溯源和线下打击。原则是发现了爬虫后，先对有长期稳定状态的特征进行标记，不要让虫子跑了：）

---------------------------------------------

Q2：问下大佬，业务系统所控制的账号，产生的确很容易，你们对账号是如何做划分层次的？如何风控管理？

A：这个可以根据一个账号的画像去做，尽可能的把账号所可以接触的权益，历史接触的权益，meta元信息，产生动作的场景都刻画下来。之后再去做的时候，其实就是个筛选过滤的过程：）

---------------------------------------------

Q3：谢谢大佬分享，关于爬虫想请教下能否分享一些具体的模型，以及技术实现？

A：常见的模型其实并不太好总结，我可以大概说一下对抗爬虫的过程。发现过程可以从两个方面去看，一个是由外向内的，比如明显的拟真行为，明显的速率问题，还有请求规模问题。这是常见的用于检测的方式，需要从请求特征，环境，收获权益的历史问题上来看。还有个是由内向外的，比如特殊的计算埋点之类的，这个可以咱之后私下探讨哈。然后内部勾结这个事情，其实可以从数据和利益方两个角度去看，从情报的角度上说，一个能内外勾结的行业，往往是有聚类性的，比如和钱和采购相关的，投放和增长相关的，渠道相关的。这些点上，传统有DLP，其实还可以从很多行为和数据角度去分析。这里不讲太多，IA或者廉政部门的手段会更丰富，我也做过几年打击内部贪腐问题，有空咱私下聊。

---------------------------------------------

——群内分享往期精彩——

--------------------------------------

本文始发于微信公众号（君哥的体历）：实录 | kEvin1986：浅谈风控安全