回归最本质的信息安全

搭建风控系统道路上踩过的坑01-信息采集

2016年9月21日发布

4,434
0
0

导语:大多数人做的产品都是目的明确的,比如订单支付、账户体系要做什么一开始就知道了,而且也有很多的竞品可以去参考;风控系统却完全不一样——未来要面对什么问题不可能完全了解。

1483520755168675.jpg

大多数人做的产品都是目的明确的,比如订单支付、账户体系要做什么一开始就知道了,而且也有很多的竞品可以去参考;风控系统却完全不一样——未来要面对什么问题不可能完全了解,做每个功能都谨小慎微,因为一个不注意走错了方向,可能就会在未来的某个阶段要全盘推翻。

而对于研发资源紧缺的安全需求来看,往往会在某个时间把自己摆到一个非常尴尬的境地,问题解决不了,改造又面临大量的时间和沟通成本。

所以,把本人踩过的一些坑在这里分享出来,让准备搭建风控的人心里有个数。

业务安全风控设计101-信息采集

业务风控主要做四件事:

拿到足够多的数据
做足够灵活的分析平台去分析数据
产出风险事件进行阻拦风险
量化风险拦截的价值和不断分析案例进行策略优化

拿数据这件事几乎是决定风控系统成败的核心,由于篇幅问题我们先主要说这点,主要有三件事要考虑:

1 拿到的数据越详细越好:

拿账号安全这件事来举例子,如果能拿到基础的登陆注册数据,就可以从频率、登陆注册特征来进行分析;

如果可以进一步拿到登陆注册行为的上下文,比如登陆前访问了哪些页面,登陆后去访问了什么,就可以从访问行为轨迹来增加更多的分析维度,例如页面停留时间,是否有访问到必访问的页面等;

如果还可以拿到用户的操作行为数据,比如鼠标移动的轨迹,键盘输入,那么可以进一步的从操作过程来增加分析维度,比如是不是输入密码的时候有过多次输入删除?是不是直接复制粘贴的账号密码?

2建立标准的日志格式:

确认好能拿到哪些数据以后,就要开始建立标准的日志格式。

常见的登陆、注册、下单、密码修改、绑定凭证修改等等都要给出一个标准的日志格式,而且要充分考虑到字段命名的统一,比如密码、用户名字段的名称如果在不同的日志中叫法不统一,在后续分析和指定策略的时候都会遇到不小的麻烦。

3拿到的数据质量:

必要的字段是否都能拿到?

往往风控关心的信息比如IP地址、UserAgent、referer这些信息业务都是不关心的,但这些信息的缺失可能造成很多策略没法做,所以在采集信息开始的时候就要有个明确的信息列表,一旦妥协了后面再去返工让研发加是会遭白眼的。

数据信息拿的是否准确?

比较常见的是需要用户的访问IP,结果拿到的IP地址是内网的服务器IP;或者是想要用户名,结果传递过来的是UID。这点需要大量的前期沟通确认工作,一旦上线了以后发现数据不对再改也同样要遭白眼。

拿数据有主动方式和被动方式两种:

1主动方式

主动方式是自己去数据库、日志里面去读。

这种方式实时性比较差,而且基本有什么拿什么,想加信息是比较难的,但不需要研发配合太多事情,适合喜欢自己动手丰衣足食的场景。

当然有些比较成熟的公司有自己的消息总线,风控可以去实时的订阅信息然后作为数据源进行分析,但这种通常为少数;

2 被动方式

被动方式就是提供接口给研发,让业务把消息按格式标准喷过来。

这种配合周期非常长,但可以按照标准来拿到高质量的信息,所以是比较常见的风控系统搭建方式。

踩坑记

1号坑:

如果拿消息是多数据源的时候,必须要考虑到消息的时间序问题:

比如登陆日志是公共服务发过来的,网页访问是拿的access_log,用户操作行为数据是页面JS或者SDK发过来的,那么这三者的时间是不一致的。

这就必须要在确认所有的消息到位之后再进行分析判断。否则,如果实时策略考虑了登陆的时候必须有页面键盘点击,而两个数据到位的时间不一致,就可能出现大量的误封造成事故。

2号坑:

对采集回来的数据必须定期的对数据质量进行监控——

已经采集到的数据可能因为技术架构调整,代码更新等各类奇葩原因造成采集回来的数据不准了,如果无法及时发现可能造成后面一系列分析过程都出现错误。

3号坑:

采集点尽量选择稳定的业务点,比如采集登陆日志,一次性在公共服务采集好,后面出现问题只要找一个点。

如果是去前端从WEB、移动端等各个调用登陆服务的点去采集,出了问题要改动的工作就会成倍增加,还有可能出现新业务点的日志无法覆盖的情况。

4号坑:

关于技术选型:

消息队列是必须的,用restful只能处理业务日志比如登陆这种1秒最多几次的类型,如果后期要去采集页面访问行为这种一秒上千的消息就必须要用到队列.

开源的可以考虑RabbitMQ或者Kafka,稳定性都还不错。

5号坑:

关于日志存储:

ELK是不错的选择,为后续的分析平台提供基本的查询功能。

信息采集往往是实施风控的最难的一个环节,但也是最重要的环节,覆盖、质量、时效都决定了项目的成败。因为出于沟通的压力,往往会有比较多的妥协,也就为后期风控系统的搭建埋下了隐患,其实也很难一篇文章把细节描述详尽。

业务安全风控设计102-风险分析

1483520356222884.jpg

上一章《搭建风控系统道路上踩过的坑01–信息采集》我们介绍了第一点,如何去获取足够多的数据,而接下来的事情就是要创建一个机制去灵活的处理这些信息,为自动分析捕捉风险事件提供基础原料,进而借助规则引擎从中分析出风险事件。

在开始前,我们还是回顾下业务风控主要做四件事:

1、拿到足够多的数据
2、做足够灵活的分析平台去分析数据
3、产出风险事件进行阻拦风险
4、量化风险拦截的价值和不断分析案例进行策略优化

接下来,同样的有三件事情需要考虑:

一、让分析人员可以快速的查询原始日志

日志并不是简单的存下来,从风控分析的需求来看,通过IP、用户名、设备等维度在一个较长的跨度中搜索信息是非常高频的行为,同时还存在在特定类型日志,比如在订单日志或者支付日志中按特定条件搜索的需求。

而这些主要是为了能够让分析人员可以快速的还原风险CASE,例如从客服那边得到了一个被盗的案例,那么现在需要从日志中查询被盗时间段内这个用户做了什么,这个过程如果有一个界面可以去做查询,显然比让分析人员用grep在一大堆文件中查询要快的多,并且学习门槛也要低得多。

如果在日志做过标准化的前提下,也可以进行后续的业务语言转译,将晦涩难懂的日志字段转化为普通员工都能看得懂的业务语言,也能极大的提升分析师在还原CASE时阅读日志的速度。

二、实时或定时的计算加工消息成变量&档案

例如在分析某个帐号被盗CASE的时候,往往需要把被盗期间登录的IP地址和用户历史常用的IP地址进行比对,即使我们现在可以快速的对原始日志进行查询,筛选一个用户的所有历史登录IP并察看被盗IP在历史中出现的比例也是一个非常耗时的工作。

再比如我们的风控引擎在自动判断用户当前登录IP是否为常用IP时,如果每次都去原始日志里面查询聚合做计算也是一个非常“贵”的行为。

那么,如果能预定义这些变量并提前计算好,就能为规则引擎和人工节省大量的时间了,而根据这些变量性质的不同,采取的计算方式也是不同的。不过还好我们有一个标准可以去辨别:频繁、对时效敏感的利用实时计算(比如访问频率、时间间隔);而相对不频繁、对时效不敏感的利用定时计算(比如用户的常用IP、设备,即使少算短期内的登录记录,也不会受到太大影响)。

三、选择规则引擎将人工策略自动运行

一个设计优雅的规则引擎是把分析师的经验决策和数据最终转化为风险输出的核心模块,首先说为什么需要规则引擎而不是选择硬编码逻辑——

笔者无数次遇到过这种场景,一个上午刚刚上线的策略,没过1个小时,攻击者或者欺诈者就已经试出绕过策略的方法了,如果你的风险控制逻辑是硬编码,那么恭喜你,再走一遍开发测试发布流程。

快速响应是安全的生命线,无法想象还有比被攻击者胖揍48小时然后才反应过来去挡脸更让人沮丧的事情了。

所以策略引擎必须能把策略逻辑从业务逻辑中解藕出来,让防御者可以灵活配置规则在静默模式下验证和实时上线生效,并可以去随时调整。

类似的开源框架有很多,各有优劣,但如果需要降低学习曲线,必须进行一层包装(这里又是一个比较大的话题,就先略过了)。

坑位标注:

1、Sharding会影响到你的策略

为了支持并发和性能,通常在利用集群计算变量的时候我们会用到sharding。

sharding方式会按IP把数据分配到不同的运算单元中去处理,在读取结果的时候按IP去集群中的某台机器中去拿数据,以大幅提升并发处理读取计算结果的能力。

那么,现在如果我想去按某个USER去拿数据的时候,就会发现一个用户在不同IP下的信息被保存在不同的服务器上了,所以单一的Sharding分配肯定是不合理的,这点必须要注意。

2、策略中用到的变量,能不用现场算的就不用

有些简易的策略引擎设计中用到的变量都是到数据库里现场算的,虽然可以极大的提升灵活性(新的变量不需要考虑历史数据回补),但会极大的影响稳定性和响应时长,尤其在业务请求爆发的时候几乎都会出现宕机无响应的问题。

要知道业务研发对安全的结果并不是那么敏感,但如果出现了问题导致应用不稳定给人添麻烦,被抛弃可能就是早晚的事情,所以变量一定要尽量做到提前计算,并且设立缓存机制。

3、对风险分析要用到的计算资源有充分的认识

毫不夸张的说,合格的风险分析要做的实时、准实时计算量要大过应用内所有计算的总和甚至超过几倍。

其实这也很好理解,比如一个典型登录场景,业务要做的逻辑最主要的就是检查密码和帐号的身份是否吻合,而风控要把这登录用户的历史档案全部拉出来看个遍,然后根据风控策略来决定是否放行。所以在规划风险分析要用到的资源时请不要吝啬,按业务5X甚至10X的标准来评估风险分析的资源需求。

如果说信息采集主要看的是安全产品经理的沟通协调能力,设计风险分析功能更多的就是考验安全产品经理的逻辑思维能力。

到了这样一个阶段,外部冗杂的沟通协调已经结束,但如何最大化利用前期打下的基础,需要对风险问题的分析、决策过程有一个非常清晰的认识,这里也有一个比较好的标准来去检验:

分析平台设计的差,那么就只有设计者自己会用;

设计的好,你会发现处理投诉的客服、分析师都会很乐意来用你的分析平台为他们解决问题。

本文为 岂安 授权嘶吼发布,如若转载,请注明来源于嘶吼: http://www.4hou.com/info/industry/2823.html

点赞 0
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

岂安科技

岂安科技

岂安科技官方账号

发私信

发表评论