阿里云WAAP方案新升级：更智能、更高效、更易用
内容介绍：
一、数字化转型中的企业安全挑战
二、Web防护-多引擎联合决策以降低误报/漏报
三、BOT管理-由静态到动态的对抗升级
四、API安全-2.0引擎下的三大核心能力提升
本次主题是阿里云WAAP方案新升级：更智能、更高效、更易用，由阿里云智能集团安全产品专家魏根慧分享。
介绍分为四个部分。第一，先看在整个数字化浪潮里，企业所面临的安全挑战。后面分别介绍wab、在bot管理、在API安全里做了哪些能力的发布和升级，给用户带来了什么新的帮助。
一、数字化转型中的企业安全挑战
先看一下当前网络攻击的态势是什么样的。对比2023年。单纯从攻击量级的角度可以看到，外部攻击的量相比去年有66%的上涨，这个数字还是相对比较恐怖的。在这个基础下凸显了两个特性，第一，我们看这个33%，我们发现机器流量的占比在整个攻击里越来越多，就是boat来自机器发起的流量占比达到了33%。第二，底下的88%，我们发现API流量的占比在用户整体流量占比里越来越高。随着API流量占比的提高， API所引发风险的比例也越来越高，有71%的客户存在API风险的。
我站在甲方的角度理解一下当前所遇到的安全挑战。在做产品之前，我也做过三年甲方的安全建设。我总结共有三点:第一，合法合规，要满足法律法规的需求，无论使等保、网络安全法、数据安全法，各保法。第二，我认为是非常核心的一点，就是数据泄露。大家作为IT或者安全运维负责人，最不希望发生的就是数据泄露。数据泄露无论对产品的运营，或对公司的声誉，都有较大的负面影响。导致数据泄露的方式比较多，比如说今天有一个搜狐注入的攻击，把库给拖走；今天有一个零内的漏洞；也可以有一个RCE获得服务器的权限；甚至今天API有一个未授权的访问，可以把敏感数据去去拉走。第三，我们的安全和运维团队希望保证公司正常业务的运转，商业利益不受损。非常典型的一个case就是来了一个CC攻击，把我元栈给干趴下了，没法正常提供业务了，业务就会有对应的死亡发生；或者在一些典型行业，比如电商或航司行业，我们有很多竞对通过boat再去爬取我们的价格，针对性比价，对商品的销售也有较大的影响。
为了解决这三类问题， WAAP解决方案就产生了。WAAP解决方案的前身是WAF，因为我们面临着不同的安全威胁，衍生出的一些高级能力，这包括了bot、 API安全、DDos防护。我也列了一下WAAP解决方案发布的过程，历史比较悠久。2012年，WAF产品开始启动内部自研。2015年，开始支持天猫双十一。2016年，正式商业化，对外提供服务。2020年，BOT管理正式商业化。2021年，我们发布了API安全。2024年，我们做了整体升级，包括前段时间的API2.0的发布、近几天会发布基础防护即waf 2.0新的迭代，后面也会把bot新版本发布出来。
二、Web防护-多引擎联合决策以降低误报/漏报
下面分别介绍在waf、bot、API上做的迭代。
WAF一直都有一个难题，那就是误报和漏报的平衡。假设我是用户，我最喜欢要的一个WAF产品是什么？我就要三点，第一是低误报，第二是低漏报，第三是不需要投太多的人力，我的预期就是这样。但从安全厂商的角度做到这样，是非常难的。误报和漏报基就在一个天平的两端，非常明显的现象是若漏报少了，那么误报就会变多，它更多的是一个此消彼长的过程。
为了解决这个难题，重点在两方面发力。第一，做了多引擎的联合决策。WAF其实在2016年就已自研发布了，它最开始上线的时候也比较简单，就是一个规则引擎。我们可以简单理解为它后端就是一个高级政策，再到后面我们发布了一个语义引擎，但我们发现有了语法、词法的理解后，检测的准招率有大幅提升。再到后来，我们在应对一些攻击变形的时候，通过协议层面再做一些控制，效果会更好。所以我们推出了一个协议合规的引擎。前面三个引擎更多的是基于已知攻击的理解。针对未知攻击更多的要学习通过数据工具流量的泛化，这里我们就引入了一个AI引擎。我们通过四个引擎做联合决策，最终实现的降漏报的目的。
在降误报和提升用户整体体验方面，我们更多的是花了两三年的时间投入AI驱动的自适应引擎。这也是AI在waf里的利用场景。我们可以先看最右边，我列了两个pro的，上面这个，人去判断一眼就可以看出来，它多半是正常的业务。但下面这个，一看就是布尔蒙柱。我们希望AI可以理解、实现人这一部分，可以判断好坏。上边这个单纯依赖规则引擎的话，它就是一个soccer注入的无拦截。我们就做了两点。第一，我们用AI的做了一个白基线训练，学习出用户正常业务的流量模式。第二，我们抽取多维特征，举一个简单例子，我们发现第一个panel正常业务通讯的时候，中文字符的数量会较多。相反，在攻击里， pillow的是不怎么带中文的，带的编码数据比较多，因为他要logo wolf，分词之后大小写混写的数量会比较多，因为它本身也是要logWAF的关键词的检测。基于这个，我们将专家经验转化成了一个数十位的特征做模型训练。最终实现的效果是当payload过来的时候，通常WAF会有一个误报，用户再去控制台上做一个白名单，做一个加白。我们有了这套自驱动模型后，就可实现AI能判定它是否误报，若是误报，它就会自动下发一个白名单去屏蔽，无需人工再介入。以上就是我们在waf上做的一个能力迭代的。
三、BOT管理-由静态到动态的对抗升级
bot的功耗对抗要比waf要激烈好几个量级。
这里我也列了三个特性：第一，自动化，今天bot的武器库在市面上非常丰富多样，并且门槛极低。假设我是一个脚本小子，我下一个东西就能搞起来了。并且，我们发现因为bot本身是趋利性的，即有钱可以赚，所以针对一些高级或职业的爬虫团队，它的隐匿做的非常好，它可能投入了几十年的团队去专门研究安全厂商的探针是什么样的、做的一些行为检测的模型是什么样的，他尽量去做反爬。
这样就引出了我们今天的一个难题，因为攻防对抗的激烈性，我们发现基于静态特征的对抗，很难再满足用户强对抗的需求了。一般来讲bot对抗靠两样东西，第一是左边的客户端，是基于端上特征的对抗；右边的是行为，端上特征更多的是依赖我们今天会注入SDK. 外部SDK也好，或者APP SDK也好，它核心就是探针，探针采集会判断今天是否为一个正常的客户端。右侧就是行为，简单理解，今天做了一个频次控制/UZIGENT的一个黑名单，它可能都是基于流量行为的检测。这两类我们做下来，最终可能被破解或者被攻击者识破当前这个防护手段只是时间问题，攻击者花两周或一个月时间就可以搞定。
为解决这个难题，我们做了bot能力的升级。我们做了两个动态化的升级。第一是刚才提的左侧部分，客户端的动态化升级。动态化升级的话分为三点， 通常，我们植入web STK如果是一个静态的，那一个比较有经验的攻击者可能花一段时间就把它逆出来了。我们要提高攻防对抗的门槛儿，就要把算法动态化掉，不允许他能很快的破解出来，包括密钥和混淆方式的动态化。简单理解为，我们开通了bot，它植入的web STK叫1，一周后，它植入的web STK叫2。攻击者可能针对web STK1所开放的破解工具在一周之后就已不适用了，以此提升攻防对抗的门槛和成本。
第二，做行为分析上的动态升级。如果一定要我选一个AI落地场景里对waf什么能力提升帮助很大，我一定会选bot。因为AI对bot攻防对抗的提升的效果比较明显。我列了四个相对比较好解释的模型特征。第一，访问时序类的特征，比如查票的业务，用户需要做登录、查询、订票的操作。但攻击者来了，可能直接就去定票了，没有前置的操作，模型就可以学习、判断这是一个异常行为。第二是操作轨迹的模型，我们基于web SDK会采集键、鼠、触的动作，在后端的实时计算引擎会把它描述成一个轨迹。我们发现正常用户真人的轨迹和攻击者通过driver或自动化发起的轨迹差异性其实很大。最后是资源异常模型，这个比较好理解。正常用户访问一个网站时，那我多少，然后CSS, 页面加载都会加上这些资源。攻击者的目的性很明显要打某个API接口，所以他直接访问最后一个API接口，没有前置的资源加载。AI理解为落地到底层，有几十个小模型帮助用户去做动态的对抗。这两个就是我们在bot场景上去落地的新能力。
四、API安全-2.0引擎下的三大核心能力提升
重点讲一下API安全的功能，和头部互联网企业交流时，他们普遍反馈API安全已经成为他们今天最重要的OKR，一定要死保、落地的场景。由于API接口导致泄露事件发生的比例已经越来越高。API安全同样也难题，它对用户的需求非常多样化，API不仅区分与WAF和boot，它是最需要去了解用户业务的，它越了解用户业务，检测效果就会越好。用户需求呈现出两极分化。第一个相对初级，我们可以理解为中小型企业想要的是什么？可能是一个初级的安全工程师，或者他都没有安全工程师，只有运维。他希望治理API风险，希望开箱即用，他内置的策略十分丰富，易用性非常高，上手直接就用了，就可以报警出来。另外一部分非常典型的就是头部的一些企业，尤其是互联网公司要求可配置性非常强，配置灵活，可以定制各种各样的模型，来满足个性化需求。为满足这两类用户的需求，我们今天发布了API安全的2.0版本。
总结下来重点有三方面的提升。第一方面就是时效性，我们花了半年的时间，从今年年初就开始投入做2.0整体的升级了。最开始我们做的是底层的离线检测的模型，可以理解为它检测时效性基本在两三个小时，这种有一个弊端就是今天我的攻击来了，可能两三个小时抱过来后，攻击也利用完了，整个事件是非常滞后的。再去处理效果也没有那么大了。基于这个背景，我们做了整体架构的升级，即API安全整体翻新了。底层的引擎升级为了实时检测的引擎，它可以做到分钟级的资产和风险预警。第二，我们在检测效果上的提升。基于整个底层架构的升级，我们在2.0上包装了更多的场景，包括风险识别、威胁分析的能力。我们新增内置了有数十种类型。第三，原始化配置。我们为满足一些头部互联网公司的一些需求，把底层所有的原子能力开放出来了。用户无论想配任何策略，都可以自己去定制。
这里我列了我们整个的功能架构。其实去年云栖大会的时候，这张图我也展示过。今年，我把我们重点发布的一些能力做了高亮，就是橙色部分是我们重点发布的功能。除了我们刚才提到的，即前面刚讲的三点功能上的提升，其实在接入方面，我们也有较大的提升。WAF是支持软件化部署的，它的目的是可以覆盖掉一些混合云、多云或是线下IBC环境。我们也支持在软件化部署的形态下支持API安全。有些用户已经有waf了或者不想用waf, 他只想用API安全怎么办？我们也支持把API安全的引擎做独立下沉，用户可以通过日志投递的方式，开一个API接口，用户只需朝API接口里吐日志就可以实现检测。
这也是我特别准备的一个架构图，就是API安全。我们分成了三层，第一层可以理解为waf的转发，简单理解，比如一个反向代理相当于流量要先到waf，waf检测后再到slower。第二层就是waf，里边包含了很多组件，比如检测中心、名单中心、计算中心及写日志的一些组件等。再到下方就是一个庞大的API检测集群。这里有很多功能，最左侧就是一个input，即waf就是API安全引擎输入的流量入口。第二个叫transform，我们做了一些decode，比如做了解码、协议解析都是放在这一层。第三，我们有一些编排，这里叫sink。比如我们有些时序的分析、聚合的统计、基线的学习等都是放在这一层。最后落到了CK里，做控制台的展示、日志的投递等。我们核心有waf了，那它是一键开启的，一键开启的效果就相当于第二部会把request和response的信息给到API安全的引擎。第二，它没有任何业务的侵扰API安全做的是异步旁路的检测，是针对被动流量做的分析，不会对用户的业务造成任何干扰。第三，它是一个近实时的检测，它可以做到分钟级的报警。
这一页就主要是我们在资产上做的一些发布了。资产也是一个非常核心的东西，是API安全的基础，我们很多团队去管理这个资产。我们重点也去发了一些东西。比如说像我们提到的，我们会罗列出来在request和response里面分别流转了什么样的敏感数据。基于这个response里面的敏感数据的类型，以及敏感数据的量级，我们会做接口的分级。可能安全团队重点关注高敏感的接口，我们也可以识别出来当前API里面有哪些接口是携带的健全信息的，健全信息是什么字段，都在资产环节里展示。
另外一点我认为可能是API安全用户最关注的一点，那就是风险。风险本身就表示的API接口的脆弱性。在接口设计之初，由于没有遵循某种规范或本身考虑不足所引发的一个漏洞。今天发布的API 2.0支持了五大类、一共有三十多种内置的风险检测。我列了几个例子，比如第一个，未授权的敏感数据泄露，无论我们是在OS针对API安全有一个单独的op ten,未授权的敏感数据泄露在排名里排第二名或者我们做红蓝或者渗透的时候也经常看到到这个概念。API安全检测逻辑是什么？它就会针对request和respond的信息做关联分析。它可以识别到那request信息里没有携带任何token特征，同时在response里边又返回了大量的敏感数据，两者加起来我们就可以判断出它就是一个未授权的敏感数据的泄露，这也会告警，用户可以发给他的业务团队，再去做关联分析。再到第二个，我们很关注弱口令登录，尤其在攻防演练或者攻防场景里，一个弱口令登录可能是非常致命的。我们也发现有很多大型的攻击最开始都是由弱口令先登进来，通过后台的运营系统作为跳板。API安全也支持我们识别request里有没有携带password的特征，它的value值通常强度又不够，这个时候就会报警。
下一个就是风险和威胁。风险由于接口本身设计的脆弱性引发，威胁就是真实已经在发生的攻击，就是已经有攻击者的在盯着我们使劲去打了。API 2.0发布了后，在威胁上也有对应的加强。当前支持左下角五大类、一共二十多种内置的威胁检测的手段。右侧我也列了一些比较典型的，第一个是平行权限的漏洞，刚才我有提到未授权的敏感数据的排第二名，第一名就是平均权限漏洞的利用，它的威胁等级非常高。我们在平台介入也基本上是在测试或者红蓝对抗里面的安全报告里。基本上靠人工的方式挖掘的。通用的工具或者产品很难解决这个问题。API安全首先是基于API接口本身建立的一个流量极限。我们可以看出来针对一个API, 大部分用户就访问一个固定的ID值，访问一个ID等于1，拿着自己的数据就完了。但攻击者来了，他发现了这里有一个平行权限的漏洞，就会使劲的去发行，他就会遍历ID等于1、ID等于2，ID等于3，一直编辑以获取其他用户信息。API安全会基于用户每个API接口的流量基线，去发现异常的高频访问行为。这里就会吐出一个告警，叫遍历爬取用户的接口数据。我们的用户就可以发现一些平行权限的漏洞。还有一些我们比较好理解的场景，比如说账号的爆破，薄弱账号的状况攻击，还有针对一些短信发送接口的恶意资源的消耗等，我们内置的策略都可以识别到。
这里的第一点就是我刚才提到的最后一点，我们支持各种灵活的原子化配置。我起了个名字叫乐高式的灵活组合检测配置。编程和内置策略其实非常丰富，支持很多类型。比如我们今天认为什么是敏感数据，一个12位的一个数字是敏感数据，用户可以直接去定义一个正则，比如今天的健全信息是什么？有API网关，所有带着token的API header都认为是有健全的，用户也可以自己做配置。用户最终都可以把这些配置落到风险检测的模型里引用。所以这里我统称为乐高式的灵活组合。
我举了一个比较简单易懂的例子，就是这些灵活的配置可以帮用户做到什么东西。我们有一个企业级用户的终端用户频繁收到竞对的电话，你来我这儿买什么东西，这个用户就担心是不是发生了什么数据泄露，手机号是怎么流转出去的，他本身的业务也是非常复杂的，但经营菠萝资产都没什么线索。他在API上配一条策略就能监控，监控所有response返回的手机号的行为，我监控到一个IP今天在15分钟周期返回了50条手机号，我们就出一条告警，用户间接的通过这种行为去监测通讯行为，就能抓到异常的调用。第二个场景，员工会撕开一些接口。企业发展很多年，后面有了API网关什么的也是一个后置行为。历史上的一些东西要去做治理。现在可能有一些业务团队并没有完整的遵循规范，作为IP/安全/运维怎么去管控API安全？API安全就是一个很好的口子去帮助用户来实现这个，配一条策略就好了。今天我重点关注，比如说API 或者过了API网关的带了线圈特征的都叫叉3，请求hydrogen也包含叉3，。同时我又去关注所有不包含他三的请求，且response里面又包含了各种各样的敏感数据。这时就要告一条告警出来，就说明可能有一个研发把接口开出去了，是一个敏感接口，同时又没有过API网关。
这也是我们一个真实的用户案例，这是金融业的客户，非常典型。在前段时间攻防演练期间，用了有两三个月的时间了，现在也在持续使用，他的痛点非常明确，就是他的业务部门很多，API接口接待频繁，业务高速发展，这里缺少API资产的抓手。他想去管控、治理，但没有任何手段。金融或者保险行业的数据非常敏感，包含大量的手机号、住址、可能更多的是医疗信息等都在里面。用户使用了API安全2.0解决方案，跑了两三个月之后，最终达到的效果如右下角所示。第一，我们先帮用户完成了接口梳理，一共发现1.8万个接口，这个用户流转的数据非常多，有7000个接口都流转了敏感数据，比如家庭住址、手机号等。用户进而分析做了持续化的运营。他每天都会投人群运营，将其中的敏感数据、失活的接口及时和研发团队做确认的下线。第二个是风险检测的能力，我们刚才有提到未授权的敏感数据泄露，基本上我们在百分之七八十的用户里面都会发现问这个问题。同样这个金融客户也发现这个问题，我们发现有数个核心接口存在敏感数据的暴露，一旦攻击者发现了这个漏洞或者风险，就可以直接把用户的保障信息拖走。第三个是安全事件的监测，我们提到了用户接入不久就发现了一个叫便利爬取接口数据，用户进而去分析他，找业务团队再沟通，发现是业务团队没有做健全，攻击者正在利用这个接口去拖一些敏感数据，API安全通过分析的功能可以发现这种事。以上就是我们在做WAF、 bot和API安全做了一些主要的整理迭代。
最后我还是想讲一下，前段时间IDC有一个评测，针对WAAP整体解决方案的技术能力做了评估，除了刚才提到WAF、 bot和API安全，其实它针对AI、威胁情报、行业应用，以及DDoS都有综合评估。右图中间蓝色的圈就是行业的平均水平，橙色的就是我们的最终成绩，其实是打满的，就是我们获得了7项能力全五分的评分，是获得了高度的认可的。最后欢迎大家尝试WAAP解决方案。
