电商平台下虚拟供应链风控技术探讨  相对于实体商品，虚拟供应链产品天生就具有更高的交易风险。我们耳熟能详的优惠券、虚拟币、充值卡、激活码、电子票等都属于虚拟供应链产品。本公众号在过去很长一段时间都在讨论实物产品的风控技术，今天我们谈谈虚拟供应链产品的风控。1实物商品风控有时间优势电商平台上的实物商品交易，永远绕不开空间转换。无论你购买什么商品，下单付款后一定还要经过仓库、物流和配送等环节，才能完整地走完购物流程。这为平台风控系统预留了足够的风险计算时间，在此期间风控系统可以随时发出指令终止流程，遏制损失。以上红色区域内任何时间点，电商平台都有机会对异常订单发起拦截操作。但虚拟供应链体系下的订单并没有类似的时间空档，这对风控系统提出了巨大的挑战。2虚拟供应链跨时空无物流环节虚拟产品以在线交易和即时交付为基础，因此一旦完成付款，虚拟产品就应该立即交付给消费者，这中间几乎没有等待的时间。试想你在餐馆吃饭，结算时正要购买一张团购券。当你完成付款后，系统告诉你优惠码需要1小时候才能发送到你的手机，你是否能接受？虚拟供应链产品交付过程中的任何时间上的等待，都会导致用户体验的下降，更不要提2～3天的物流派送时间。3虚拟商品可复制，一经发货覆水难收       类似于团购激活码、会员充值码、门票兑换码这类虚拟商品，一旦商城发货，消费者就可以立即明文获取，并且能够快速复制和传播。电商平台通常都不可能直接获取已发货电子商品的使用状态，因此也无法在发现交易风险后快速撤销订单，取消“发货”。举个例子，如果某电商平台X和迪士尼合作在线售卖迪士尼门票。如果下单人员就站在电子出票机前，前手下单后手就从自助机上取出门票。就在订单发生5分钟之后，电商平台X通过数据分析发现这笔订单存在欺诈交易风险，试图拦截交易。但因为此时电子码已经被兑换，取消订单已无意义……当然在某些场景下，电商平台可以和线下供应商进行沟通和协调，取消或冻结某些电子券，但总体来看成本（时间、技术和商务）非常高，成功率难以保证，风险不可忽视。上述业务特性就决定了虚拟供应链安全不容忽视，那么典型的虚拟供应链风控场景包括那些呢？4虚拟供应链安全典型风控场景团队在过去一年里与黑灰产在虚拟供应链交易环节做过无数PK，以下是我们总结的典型风控场景，希望对您有帮助：盗卡交易 & 盗号获利盗卡交易 通过诈骗、木马等手段，盗用他人银行卡在平台购买虚拟产品。因为省去了仓库调拨、物流配送等环节，黑产可以快速购买商品并转手销赃。这类交易后期的损失和赔付往往由电商平台承担，因此风控系统必须能够遏制绝大多数的盗卡欺诈交易。盗号获利 通过盗号攻击（例如以密码重用攻击为基础的身份盗用，也称为“撞库攻击”）获取大量用户身份，消费这类用户账户内的虚拟资产，购买虚拟产品等。例如，某电商平台支持以X豆兑换Y游戏的点卡。批量养号 & 并发获利批量养号 批量注册账户，并长期循环登录保持活跃，“积极”参与电商平台的各类领币、领券、赠积分等活动。等到账户内的积分、虚拟币等攒到一定级别，就可以转手倒卖或用于购买低价商品。并发获利 工具党在利用积分、币、豆等兑换其它虚拟产品时，利用竞态条件采用并发操作的方式，产生多笔交易。例如，电商平台X网站开展活动以20积分兑换1个某视频网站黄金会员激活码。某用户账户只有20积分，但同时开了10个浏览器打开相同的兑换页面，以最快的速度同时向网站发起兑换操作。如果后台系统没有对账户积分做资源锁定，则很有可能该用户能够一次性兑换多个激活码。套现获利 & 破解算法套现获利 利用网站业务逻辑漏洞获取虚拟资产，再通过其它手段将虚拟财产转换为人民币资产从而实现非法套现。别问我怎么做到的……破解算法 互联网上典型的虚拟产品是类似于优惠券、激活码、充值码等字符串形式的数字信息；最常见的形式，莫过于一串数字字母组合。以充值卡为例，好的充值密码在设计上做过充分的安全设计，特别是长度，字符类型等。但也有些厂商的充值密码存在重大设计缺陷，导致可被批量枚举，例如：某充值卡激活码样式类似SH81982。该验证码长度有限，且前两位是分销商区域标识（SH，上海）。攻击者在网站激活完全可以遍历最后5位数字。以现在的互联网速度和计算能力，用不了多久即可获取大量充值卡密码。5虚拟供应链风控建设由于众所周知的原因，我们不在这里就技术实现的细节做展开讨论，但虚拟供应链风控的基本思想和策略还是可以和大家分享的。我们已经知道虚拟供应链与实体商品的售卖有重大的区别，因此对虚拟供应链风控系统、策略也提出了大量的挑战。风控系统必须能够做到精准识别风险交易，快速给出判定结果，有效地控制误报率和漏报率。推荐的一些思路如下：5.1 使用同步和异步两种风控策略为了提高虚拟产品购买体验，加速购买流程，风控系统必须提供强大的同步服务调用能力。业务系统在调用风控后，必须在数十毫秒内得到明确的结果，如：是否允许下单，是否允许付款等。针对单个交易，同步风控调用固然有效；但有些情况下异步风控仍然不可或缺。产品、业务方应该在尽其可能的情况下，提供风控系统异步决策的业务拦截机制，以应对那些通过跨时间段统计分析才能识别风险的欺诈交易场景。5.2 建立特定标识的黑白名单历史积累数据对风控决策有重要帮助作用。风控系统必须能够进行近实时、离线等数据计算，将计算结果写入某些中间集合。黑白名单是一个非常典型的技术手段。如果某些用户ID、IP、设备号等已经被列入黑名单，则风控调用过程中完全不需要再走风险计算逻辑，直接根据黑白名单即可输出结果。该方式将大大缩短风控响应时间，在保障安全性的同时提升了用户的购物体验。5.3 做好项目安全评审项目安全评审不仅仅包括代码安全评审，还包活从项目发起时的需求评审。例如公司要在线上做一期免费领券看电影的活动，那么风控团队就要评估：这个项目的在线活动是怎么个玩法（活动规则），主要风险点在哪，攻击者会使用何种方式来获利，现有的风控系统能否支撑该场景下的风险控制，是否需要调整部分规则规则以规避潜在的风险等。

需求背景公司运维团队已经完成了针对分布在各个分支机构的交换机、路由器和防火墙的 syslog 日志的收集。安全基于 ISO27001和等级保护建设的需求，也希望收集此类设备的日志进行安全审计。虽然主流的网络和安全设备都支持同时向多个syslog 目标服务器发送日志——双发或多发；但是，为降低链路带宽占用，安全和运维就日志收集方式进行了技术讨论。最终决定放弃双发方式，而是对运维收到的日志进行转发。该方案的优点是：运维团队不需要对1000多台既有设备做任何配置变更；同时，链路上只存在一路日志收集，带宽能够得到保障。运维的日志还可以转发给多个目标，如安全、监控中心等。据了解，目前运维使用了 RSYSLOG 作为日志收集和存储的服务端。幸运的是RSYSLOG 支持日志中继转发这一高级功能。日志流转示意图下图展现的就是本次日志收集和转发的逻辑：关键是运维同事需要如何配置RSYSLOG才能实现转发日志给安全团队，让我们来了解下原理。技术原理”RSYSLOG is the rocket-fast system for log processing“，有什么问题请访问网站：http://www.rsyslog.com/ 。按照 rsyslog.com 的说法：RSYSLOG提供高性能，极好的安全功能和模块化设计。 RSYSLOG已然从一个常规的系统日志发展成了瑞士军刀，能够接受来自各种来源的输入，也能转换和输出到各种目标系统。在特定处理场景下，RSYSLOG可以每秒向本地目标设备发送超过一百万条消息（基于2013年12月的第7版）。 即使发送到远程目标系统并加以更精细的处理，其性能通常被认为是“令人惊叹”的。来看看支持多线程、UDP、TCP、SSL、TLS、RELP、过滤器、配置输出等特点的企业级日志中继服务器 RSYSLOG 吧！配置实现要实现文章首节提出的日志转发需求，通过以下步骤可以实现。首先，配置/etc/rsyslog.conf文件，加载 UDP/TCP 的syslog接收模块，并设置监听端口。注意，如果你要需要 rsyslog 监听UDP 514端口，还需要设置 SELinux，否则该端口无法使用。第二步，配置日志中继转发的目标。此处举例，将日志以 syslog 方式转发到安全团队的 Logstash 日志收集代理服务器192.168.21.2。最后，执行命令service rsyslog restart重启 rsyslog 服务，静待日志从远程设备发到 rsyslog 再中继转发到安全日志收集代理！高级参数下面将介绍RSYSLOG的一些高级参数，你将看到高级参数数如何满足定制化需求的。日志分类存储以下配置参数，可实现不同交换机设备IP 的日志转储到不同的日志文件。这是目前运维团队正在使用的配置。根据日志类型和优先级设定发送目标除此之外，针对特定日志类型，我们还希望能转发安全日志收集代理，请参看如下配置:对日志字段或内容进行过滤判断对本机日志进行过滤更多日志发送目标日志转发到 Kafka日志转发到 MySQL其它不对特定的日志做处理。参考资料RSYSLOG 的条件过滤请参考：http://www.rsyslog.com/doc/v8-stable/configuration/filters.html基于传统的severity 和 facility的过滤基于属性值的过滤器基于表达式的过滤器BSD-style风格过滤器（不向上兼容） RSYSLOG配置过程中可用的变量或属性参数：http://www.rsyslog.com/doc/v8-stable/configuration/properties.htmlrawmsgmsghostnamesourcefromhostfromhost-ipsyslogtagprogramnamesyslogfacilitysyslogfacility-textsyslogseverity-textsyslogseveritytimestamp一定要参考的一篇文章《日志收集之rsyslog to kafka》

知识图谱在风控的应用简述  从校内到人人，微信到陌陌，我们早已熟悉各式各样“你可能认识的人”，”六度空间”理论早已深入人心。社交软件通过不同人的社会特征将大家关联到一起形成一个庞大的社交网络。同样，在电商的客户里我们有上亿各种类型的用户，我们是否可以分析出他们之间的关系？这些用户里有好人也有黑产，我们是否能从这些关系里推断出谁可能是正常用户，谁可能是黑产，从而将这些数据应用到风控中，从而识别潜在的风险交易？我们尝试将“六度空间”映射到风控领域，构建一个用户知识图谱。2012年以前的语义web中描述一个人可以是“23岁”,”男”,”江苏人”，“三多”“许三”，这些描述都映射到“许三”，许三被称作“本体(ontology)”。“许三-性别-男”这样的“资源-属性-值”的描述方式称之为RDF（资源描述框架）。当我们构建无限多个像许三这样的本体之后就形成了一个本体的集合，就可以研究“属性-本体”，“本体-本体”之间的关系，他们可以兄弟也可以是父子，甚至可以判断外号三多和许三是同义，代表同一个人，这样就形成了一个人与人之间的关系网络。2012年，google推出了知识图谱，知识图谱的本质还是语义web，将本体从学术引入到应用。知识图谱构建了一个基于图的数据结构，将现实世界的实体（学术本体）关系通过点和边来描述，实现了一种更有效的展示本体之间关系的网络，也给我们提供了一个通过关系去分析问题的方式。简单来说，知识图谱就是把所有数据信息通过关系连接在一起形成的一个关系网络。在风控领域里，我们尝试用知识图谱去描述两个人张三和李四，当张三和李四曾经都使用同一个收货手机，那么我们可以通过手机来为两个人建立一个关系，如下图：在风控领域我们描述一个用户有以下常用属性：用户id，注册手机，注册时间，注册ip，登录ip，登录时间，收货手机，收货地址，设备指纹，实名信息，银行卡，支付信息，行为信息等。概括出来，知识图谱在风控领域的应用主要分为以下几个部分：1.      关联识别2.      聚类识别3.      推导识别4.      异构识别5.      碰撞检测6.      同义识别简单举例，实际情况比示例要复杂的多。1.关联识别1）关系识别匿名用户与登录用户匿名用户A与登录用户B拥有相同的设备指纹，客户端信息等，可以初步推断匿名用户A与登录用户B是同一人，若A有风险行为，则B的操作不可靠。2）行为识别撞库行为识别用户账号A，B，C……等账号在同一个时间段内在同一个设备上有尝试登录的行为，可以推断此时存在撞库风险，对此时登录成功的账号应发起改密提醒。2.聚类识别由于资源的有限，黑产总会最大程度利用资源，在很多不同的注册，登录，下单的场景中，看似独立的每个用户可能因为共享有相同的手机号码，登录ip，下单ip等信息而形成一个聚合集体，这个集体很容易从知识图谱中识别出来。在应对刷单的场景中，黑产为了能够收到刷到的商品会将收货地址选定在某个固定的区域内便于降低收货成本，通过对收货地址的区县聚类，可以形成一个以地理位置为维度的知识图谱，通过对图的规模识别来反映刷单风险。3.推导识别用户账号A与B拥有相同的手机号，用户账号B与C拥有相同的收货地址，则可以推导A与C是存在关系的。如果在某个营销活动里，用户A推荐了B，B推荐了C，C推荐了D，如果判定A为黑产则可以推导这个图的节点上所有用户都疑似为黑产。金融风控领域，在贷后催收过程中如果被催收人A失联，可以通过知识图谱找到与A关系相近的其他人，进行追踪。4.异构识别在一个时间段内用户A的知识图谱的关系结构有较大的变化，有关系的断开也有关系的变更，就要关注这部分用户的信息变化，识别潜在的风险。5.碰撞检测同一个时间，订单1收货手机A对应的收货人姓名为许XX，订单2收货手机也为A但是收货人姓名为李XX，则A的手机归属人存在冲突，存在潜在的风险。在金融领域，用户填写个人信息，公司信息的时候，可能存在虚假信息，比如A填写的公司为G1，地址为“上海市闸北区”，公司电话为“021XXXX”，用户B填写的公司也为G1,地址却为“上海市闵行区”，公司电话为“021YYYY”，此时同一个公司有有两个地址和电话，可以判断为信息冲突，需要核实两个地址是否为同一公司。6.同义检测在用户填写信息中如已确定“唯品会”与“四行天地”为已知正确关系，如其他用户填写“唯品会（中国）”与“四行天地”，通过相似度匹配可以认为“唯品会”与“唯品会（中国）”为同义词。之前我们提到，在RDF中可以构建一个同义词的关系，用知识图谱建立该关系，可以在碰撞检测中去除掉一部分同义词产生的碰撞，使结果更加的准确。了解了应用场景，下一步就是将理论上升到实践中啦。点击以下链接，查看完整内容：http://mp.weixin.qq.com/s/JhHtt1piAOROR5RSJtLGzw

APP安全之通信安全（下篇）既然APP通信存在诸多安全问题，那么究竟如何才能提高APP的通信安全呢？对数据做HASH加密校验（1）在so文件中进行HASH校验，即KEY+parameters，当然也会对KEY进行混淆，但KEY保存在APP本地迟早是要泄露，更好的做法是使用动态KEY。（2）有效利用APP的签名证书，服务器端使用该证书的私钥加密动态KEY发送到客户端，客户端使用从本地APP中获取到的公钥信息解密得到KEY，然后进行签名。（3）重打包过的APP，获取到的公钥信息与官方APP不同，就无法解密得到动态KEY，从而可以在一定程度上预防重打包。当然实现上需要注意，如图6为获取APP公钥信息的函数。（4）若在需要动态KEY的地方调用该函数，重打包时只需要修改该函数返回值，就可以被绕过，正确做法应该如图7所示。在APP的多个功能处使用本地公钥信息，可以一定程度解决重打包风险。所以，在APP通信安全方面，应优选SSL Pinning方式的HTTPS的传输和动态获取KEY方式的完整性校验。点击以下链接，查看完整内容：http://mp.weixin.qq.com/s?__biz=MzI5ODE0ODA5MQ==&mid=2652277120&idx=1&sn=ece9ce6624b141a305aa8a7f7a9f068d#rd