业务安全与风控

对抗原则

相对的风控而非绝对的防黑
增加黑产的成本而非阻断他们的行为——假如投入成本超过损益点，那就没必要薅你羊毛或者攻击你
永远的情报——深入敌后，爬虫与QQ群
方法比技术更重要——技术对抗是无止境的，改变战场规则可能起到一招退敌效果
数据比算法更重要
勤能补拙——不断改变业务逻辑，不断升级使对手疲于奔命
忽略性能、用户体验和成本的风控没有意义
纵深防御——由机器规则处理最原始数据，逐步筛选过滤，最后人工审核
杀鸡给猴看——只要条件允许，用法律武器断掉主力，用风控手段扫尾
人民的战争——教育用户安全意识，鼓励全民情报
社工库——敌人有的，我也要有

账户安全

注册

对抗垃圾注册:

图片验证码
邮件验证码
短信验证码
语音验证码
电话语音验证码

密保/密码找回

应提供多种密码保护手段：密保问题、安全中心手机版等

密码找回/重置不能存在逻辑漏洞或者过度的信息披露

提供异地登录提醒、异常登录提醒、破解账户提醒。

找回密码需要人机识别，方式批量找回

多因素认证

在密码找回、重置、安装证书等重要操作需要启用

多设备都能

保证同平台不能串号：PC和APP可以同时登录，但是两个PC不能登录同一个账户

假如登录就要踢下线

账户共享体系

单点登录（Single Sign-On，简称SSO）是一种身份验证和授权机制，允许用户使用一组凭据（如用户名和密码）在多个应用程序或系统中进行身份验证，而无需为每个应用程序单独登录。

常见的SSO实现协议包括SAML（Security Assertion Markup Language）、OAuth（Open Authorization）和OpenID Connect等，这些协议定义了身份认证和授权的交互方式和流程。

但是凭借一个token就登录所有应用不是一个好设计，一旦xss盗取了，相当于全线溃防。一般对高安全域的，比如个人认证信息、支付类等重要的，引入第二层认证的secure token，只有一个token登录不了重要应用，需要两个token才可以。

电商类

恶意下单

拍下商品但不付款：高峰时段下单使用验证码

黄牛抢单

风控：小号、僵尸号与正常用户的区别、登录的途径、登录地域、登录设备指纹、收获地址等里啊分类标记

也可以临时更换业务逻辑使抢单程序失效；在抢购过程中使用验证码做人机识别

刷优惠券和奖励

根据大数据标记用户恶意灰度。给优质账户高额回馈，低信誉小额优惠。

反价格爬虫

主要是竞争对手比价

爬虫特征：爬虫所在的IP段、不是正常的浏览器、可能不会解析JavaScript、缺少正常的浏览器客户端行为和通信（跟DDos中的CC攻击人机识别有点类似）

反欺诈

根据账户注册信息的真实性、登录设备的真实性、绑卡异常、账户异常，结合自有或第三方历史征信数据综合判断欺诈的可能性。

可能包括：虚假商品销售、钓鱼网站和假冒店铺、虚假评价和刷单、虚假退货和售后服务、虚假折扣和促销手段、虚假投诉和纠纷

信息泄露

来源：撞库、用户信息过度展现和披露、开放平台API滥用、供应链上下游信息泄露、内鬼兜售内部数据

成熟的大公司英国建立执行隐私保护的标准，对数据分类分级，加密脱敏。

交易风控

依赖于以下几个方面：

账户安全
客户端安全：反钓鱼、反木马
认证机制：证书PKI（Public Key Infrastructure，公钥基础设施，是一种安全框架，用于管理和分发公钥证书以及支持加密通信和身份验证。）、令牌、多因素认证
风险评估：账户历史行为、历史征信数据、交易和账户异常、漏洞模型筛选：机器规则+人工审核

交易风控在传统安全（包括认证、账户、KMS、PKI、客户端完整性等）的基础上还需要由3大组成部分：

用户数据、交易数据
来自传统金融行业的风险管理
基于大数据的风控平台

交易风控团队需要两拨人：一来自传统金融行业，另一个来自互联网

广告类

点击欺诈，数据作假，所以目前都是按广告效果，实际订单效果收费

CPM（Cost per Mille）： CPM指的是每千次展示成本。
CPC（Cost per Click）： CPC指的是每次点击成本。

这两个都不行了，需要CPA（Cost per Action）： CPA指的是每个行动的成本。

广告联盟优势跟黑产一样，假装正常用户注册登录充值，小量消费，只要消费低于广告费它就是赚的。

需要依靠账号标签以及对用户行为模式的数据分析来获取

媒体类

主要是黄赌毒、舆情安全

基础手段：敏感字过滤、举报功能、人工审核
高级手段：抓取样本，用机器学习的方法做特征识别

网游类

除了盗号盗充，主要问题就是反外挂、私服、打金工作室

“打金工作室”通常指的是一种非法或违反游戏规则的活动，主要是指在网游中以非正当手段获取虚拟货币、装备或其他游戏资源，并出售给玩家获取利润的组织或个人。

这些打金工作室往往使用外挂、作弊程序、恶意刷钱等手段来获取游戏内的财产，这种行为严重破坏了游戏的平衡性和公平性。

保护手段：

客户端：代码混淆、加密加壳、反调试
网络封包：对抗重放型攻击
服务端校验：大部分逻辑校验放服务端，校验时钟同步
人机识别
产品内容设计：物品与账户绑定
运营数据监控
私服：供应链管理，研发到运营的交付，研发的信息安全管理，运营平台防黑、研发团队集体跳槽的知识产权保护，主创人员敏感异动预警，竞业协议，保密协议等

最后还需各种情报的收集

云计算

这站在云计算平台厂商角度看， CaaS（Crime as a service），出了黄赌毒、很多虚拟机实例被植入木马变成“养鸡场”，僵尸网络的集中地，频繁DDos其他IDC或者用于暴力破解密码

云计算平台厂商可以做的是基于网络的异常流量分析

大规模纵深防御体系的设计与实现

设计方案的考虑

防护手段：

安全域划分 /VPC /VLAN隔离
OS加固：比如目录的wrx权限，cgroup+namespace+chroot
最前端的抗DDos防护
4层防火墙的过滤

检测手段变现为一个个相对独立的产品形态，而防护则更多以零散的手段分布各处

数据流视觉

1.网络(安全)设备：防火墙、WAF、NIDS（在大型IDC这些产品可能不一定是盒子，而是分布式软件，module或agent的形式）
2.OS层：HIDS数据，系统原始日志，应用层日志
3.运行时环境：JVM、Zend解析器的定制日志，形式上属于OS层面可以采集的数据
4.数据层：数据库、缓存以及大型的分布式数据库中间件代理所产生的访问和安全告警
5.漏洞信息：由网络扫描器或主机本地agent搜集的漏洞信息
6.资产和配置管理数据：iplist属于基础数据

上面做得比较好，可以考虑第三方威胁情报数据（IP信誉、恶意域名、灰色URL）

服务器视觉

服务器负载均衡可能会充当WAF和人机识别模块

应用需要RASP运行时环境的沙箱检测

HIDS

大数据日志采集agent（比如Flume）

SQL / DB审计

IDC视角

IDC跨全球区域，一般跟随运维基础架构，比如运维是多中心分治，安全数据也不会可以最求到汇聚点聚合。

敏感国家地区遵从合规性，可采用区域分治原则

逻辑攻防视角

对于企业的生产网络，最外围的威胁如下：

4层流量型DDoS
DNS瘫痪
链路劫持

最外层抗DDoS
之后快速收敛入口，减少攻击面（Firewall：4层防火墙）
应用层防御：HTTP(S）是WAF，其他协议NIDS，CC等7层DDoS可以使用7层的抗DDoS人机识别，通常类似WAF的软件模块
之后是7层更后端的应用代码的运行时状态，一般以检测webshell为主，小规模环境可以用RASP模块检测OWASP TOP10的大多数漏洞类型
再往后是应用层与系统从之间：sql注入或拖库——SQL审计，SSH暴力破解——系统日志分析，直接调用系统命令并未完全获得系统权限——webshell检测
攻击链末端是获取系统权限：防御者模型是检测提权和rootkit，对应的解决方案通常是HIDS

不同场景下的裁剪

上面上全套对于大多数企业来说还是太贵，只能做一些妥协和裁剪

IDC规模大小的区别

4层抗DDoS的成本很高，也可以依赖第三方，不要对效果有过分的期望
没有条件做网络分光，就老实扫描器+Web日志分析也能顶用
自研HIDS是奢侈品，市值小于100亿美元，建议用现成开源的
RASP也是奢侈品，WAF不能很好利用就不要去弄
SQL审计也有点小奢侈，如果有较大自行能在CGI层解决SQL注入，也可以忽略这个

不同的业务类型

如果业务流量大部分是http类型，重点投入WAF、RASP和WEB扫描器，NIDS/NIPS可以忽略，如果有条件搞HIDS，优先关乎用户态检测，比如webshell和提权

而非HTTP协议，如SSH、MySQL等通用协议而不是私有的话，网络部分可以考虑NIDS，数据库部分使用SQL审计。

而小西街口、远程过程调用、数据缓存和持久化中私有协议占多数，就不考虑NIDS和SQL审计，而转向HIDS，私有协议对于入侵者来说是一道门槛，被渗透概率不搞，所以更多关乎操作系统本身。

非web业务，入存储节点，关注操作系统入侵，HIDS，重点在后门程序和Rootkit的检测

安全感的底线

无论如何追求性价比，安全感总有一个底线

入侵者能随意操纵数据库/用户数据（不一定需要数据库权限或者系统root权限）
渗透到达了操作系统这一层（得到了shell，无论是普通用户还是root）

最起码对于这两个环节上具备一定的入侵感知能力，不至于发生了如此严重的事情还没有半点告警，

所以尽可能在数据库（或者数据访问层（Data Access Layer）：DAL是应用程序与数据库之间的一个中间层）和主机这两个层面设防。

分阶段的安全体系建设

宏观过程

第一个阶段是基础安全策略的实施
第二个阶段是进入系统性建设——各个维度的安全防御手段
第三阶段，系统化建设，安全运维和SDL成体系后，可以选择性关注业务安全的问题（通常以账户安全为切入点，之后选择主营业务中风险最大的IT流程活动做相关的业务风险分析和业务封控体系建设）
之后是进入运营缓解，把每一个防御点打磨到极致。
最后进入自由发挥区间。

清理灰色地带

第一阶段：

资产管理的灰色地带（资产管理系统数据不准确，遗漏安全检查和监控，或者急忙上线漏掉了安全扫描）
安全措施的覆盖率和健康状态
ACL的有效性

第二阶段

清理远程登录弱口令
清理Web应用的漏洞：SQL注入、文件上传点、struct2等RCW漏洞
清理服务器端口：盘点不必要的服务和协议，排查高危端口

之后投入到纵深防御+入侵感知体系建设才会事半功倍

建立应急响应能力

组织

运维：补丁和配置更改的具体实施工作
产品团队：代码级别的漏洞修复
安全防御体系建设小组负责在相关的乳清感知体系中update对于该漏洞的检测规则

流程

一般性漏洞与普通bug修复流程一样
对于比较严重的漏洞，通常由安全、运维、产品的leader开会制定专门的漏洞修补和应急计划
修复时效：根据漏洞类型和影响程序决定
对于短时间无法修复，可使用临时规避措施

技术

发现得快依赖于乳清感知体系
修的快依赖于持续集成和自动化发布工具的支持
同样，自动化运维能力主要属于运维的职责，也会影响漏洞修复和安全策略的实施效率

总结：1.发现得快；2.修得快；3.修不了，临时规避

运营环节

比如漏报的根因分析流程

单点检测深度不足?——选取的检测维度不够?——覆盖率不足？——安全产品的可用性？——数据质量？（数据非安全相关或者中低风险的告警太多）——人的问题？