WAF误报指标控制怎么做；如何保护本地信息安全 | FB甲方群话题讨论

本期话题抢先看

1.切割WAF里有没有什么具体的误报指标值，达到这个值的时候，可以切换成防护模式了？

2.如果小区使用单IP出口 ，IP下有黑产WEB攻击、刷单，也有正常用户。这个IP封不封？

3.手机端、手表端本地个人信息如何做安全措施，是做到库文件级别，还是做到字段级别，还是库文件+字段？

话题一

目前我们在切割WAF，共有10个站点需要防护，当前均处于检测模式，后面逐渐改为防护（拦截）模式。因为当前还有很多误报，策略待优化，想问一下一般有没有什么具体的误报指标值，达到这个值的时候，可以切换成防护模式了？

A1：

0，业务对假阳性阻断是零容忍的。你可以假阴性，但是不能容忍假阳性阻断。

A2：

0暂时达不到，设备本身的策略颗粒度不行，没法分级阻断。

A3：

分析数据，看能优化到什么程度。误报出现一类处理一类，复盘过去一个月的数据，看能收敛到什么程度。

A4：

是的，调整是打算这么做，就是不知道切换模式的时候，用什么来评判。

A5：

这个没有硬性标准吧，和业务商量收益（拦截多少）和风险（一天大概误报多少，影响多少业务），做好误报处理流程，业务能承担就上了。我没实际搞过，只是理论说一下。或者从上到下推，不上WAF不让上线。

A6：

是旧WAF换新WAF，原有策略没法100%迁移。

A7：

贵公司什么行业？如果会参加国家或者地区HW机会的话是个切拦截模式的契机，就是要同步推进，抓紧时间窗口跟业务和应用一起理策略，提前准备和协调也比较重要。

A8：

提供一个思路，其实还有很多管理方面的手段，但是绝大部分IT和安全部门是搞技术出身的，这种道道不精通，很多事情基本都是能靠向上管理解决的。

A9：

提取下拦截信息，计算召回率、误伤率，提供基础数据支持；提供业务反馈渠道，用户投诉处理；WAF 拦截开启计划，优化规则到什么程度（基础数据表现）能够开启拦截，与业务沟通定下标准。

A10：

确实是应该向上反馈一下，提供基础数据，上面来拍板，不能我来瞎想了。

A11：

基于攻击者画像拦截，还不敢说 0 误伤呢，更别说WAF参数单一了。如果有能力与资源，做好业务分类。不同业务不同规则，按照业务信息收集情况去制定，误伤还会有所降低。

A12：

WAF 这事情特别耗精力，还有可能费力不讨好。讲标准汇报时候不够清晰，业务不够认可，出问题还会直接影响业务，谨慎点吧。

A13：

特别现在行情不好，和业务强关联的，谨慎一点。

A14：

矛盾上移吧，WAF误报是无解的问题，要么找到的全部例外，要么某一项不检查，但是不开拦截要WAF还干嘛，靠人24小时去盯日志吗？

A15：

搞WAF没这么多弯绕，基础功能基本上就WAF的规则库管理，还有域名管理，黑白黑名单管理这些，升级一些的加个威胁情报模块，Bypass功能啥的，看需求了。自研的话其实没必要搞那么多没用的东西，功能越冗余，越容易出问题。 还有我说的是WAF的安全运营管理，不是指的开发WAF，没那个技术。

A16：

WAF对于甲方来说是有必要上的，但是上WAF肯定是需要获得业务条线肯定的，甚至是培养他们的意识，觉得接入WAF，他的业务才有安全保障。这个需要宣贯，也需要确实给有效果。 其次，WAF接入最大的阻力，或者说业务部门担心的点，就像前面说的，阻断是最大的问题。那么想要让他们肯定你的WAF，回退方案，一键Bypass的功能就得整出来，落到实处。

A17：

甲方WAF是要承担业务稳定性要求、防BOT等等的功能。

A18：

你说的业务稳定性的问题，这个就是你WAF架构设计的问题了，对于突增的业务流量怎么处理，这个和规则没太大关系，产品架构问题。 其次初期上WAF，开阻断的时候建议上些边缘性的业务，通过内部模糊测试，和外部流量的验证后。确定规则误报，等误报率下去，一般厂是没这个能力优化的，乙方的WAF更是标品，不可能专门针对你们家去优化的。

A19：

这么讲吧，我2018年在Topsec负责IPS引擎维护，最近在头部公司梳理WAF相关SOP与建设需求，都是一些个人理解吧，我也不敢保证，个人理解就是一定适用于所有企业，可能每家都有自己特点。

A20：

开WAF策略不能全开，最好开一些基础的和一些你关注的专项规则（比如Log4j2的），不懂的最好别开。想用就开个监控，以触发频次，IP威胁情报等综合维度结合着封禁，阻断是合理的，阶梯式的触发规则。

A21：

Bypass之后就不要想着重新Unbypass了。

A22：

Bypass这个功能其实是甩锅用的，你WAF一旦上了，你会发现个现象，任何业务出了问题，业务部门都怀疑是你WAF导致，这个时候，你第一时间Bypass，关停你的WAF防护措施，是最明智的，这样如果问题还在，肯定和你没啥关系。

A23：

先上灰度，然后慢慢按百分比切流量就行了，没让业务流量一上来就全切过去。

A24：

各种策略吧，有的企业还真没有按照百分比切流量的机制，一个盒子扔到现网，甩给运维玩去了。

A25：

还有就是最好是让业务部门主动要求，申请（邮件，流程审批）接入WAF，最好阻断防护能精确到接口级别，这样就算发生误阻断也是仅限于接口级，而不是全站。

Q：提个问题，如果小区使用单IP出口 ，IP下有黑产WEB攻击、刷单，也有正常用户，这个IP封不封？

A26：

你这个问题分了两部分，有一部分是风控能力解决的，至于IP的问题，只要他的出口IP没有被威胁情报标识成恶意IP，你封他干嘛。 至于刷单的问题，WEB攻击的问题还是上面说的，视触发频次以及其他的维度，阶梯式的去执行封禁策略。

A27：

基础数据指向这个IP，为恶意，但是下面有正常用户，封还是不封IP呢？风控解决不了WEB攻击的问题呀。

A28：

单纯的恶意IP，还得看请求内容。如果确实有大量的恶意请求，并且触发了你的策略。那就封，影响业务了，自然会有投诉过来，没有的话就是不影响。而且封禁IP也不是一直封，也是阶梯式，触发到第一Level封多长时间，第二Level多长时间。安全运营的同学可以根据业务经验去定。

A29：

不封怎么判断是否影响业务呢？影响业务具体多少能封呢？有些业务自己不见得能知道。

A30：

可以投诉啊，就是影响用户了，用户反馈给客服，客服反馈给业务，有用户反映用不了功能了，具体啥特征。而且你这种场景。需要的是面向个人用户才会有影响，面向企业级客户的业务和这个处理方式不一样。不投诉的话，就没影响，你给业务条线操那心干嘛。

A31：

安全运营+WAF运营成背锅侠了呀。

A32：

阻断性质的安全设备都存在这个问题。这也是RASP这个东西不好落地的原因。WAF是等保要求的，所以没办法，RASP不是，所以安全设备大多数是做的入侵检测，不是入侵阻断。

A33：

给大家分享一下WAF切换最终做法，拉着网络那边的老同事，把资产梳理了一下，最终排查出3个重要的，拉领导报备切换计划，同时让他们给开发知会，其他不重要的，自行与开发、客服沟通，约定好切换时间，没啥问题就保持，按照1天策略优化（找厂家支持）、1天试运行（值守）、1天正式运行，这样来搞。 上周我们上了WAF，还没改拦截模式了，每次系统有啥问题，开发会先是不是WAF拦截了，这是很自然的反应。

A34：

约定好拦截的返回状态码和页面，这样看到这个页面和状态码就知道WAF拦截了。

A35：

好主意，希望有这功能，之前的WAF倒是有对应的明确拦截页面。

A36：

业务Down了，第一时间不是系统厂家查故障，而是要你看有没有攻击，哪个部门（无论是不是安全的）割接，接下来一周出故障，会先问是不是割接造成的。

A37：

小技巧，将WAF拦截界面换成安全狗的拦截界面，攻击者会受到拟态防御的影响。

A38：

拟态防御是啥意思？

A39：

可以这么理解。攻击者判断攻击是否成功或者应用是否受到漏洞影响。基于HTTP响应数据、延迟、侧信道数据(带外通道)，只要响应数据是假的，攻击者会产生误判。

A40：

拟态防御和正常的攻击防御不都是一个样吗？只不过换了个名词好听一点，实际没啥区别。

A41：

虽然定义不清楚，但是我知道其中一种实现，在关键防护页面上，客户端请求以后，用PHP和Python两个代码执行，并比较返回值，如果返回值不一样，认为有攻击。这个是一些比赛里面考过的，实战不知道有没有应用。

话题二

手机端、手表端本地个人信息如何做安全措施，是做到库文件级别，还是做到字段级别，还是库文件+字段？

需要考虑以下问题： 1、终端本身性能问题 2、终端加密后同后端交互的业务复杂性

3、如果终端数据泄露，这个影响又如何判定呢？同拖库级别来说，单个用户信息泄露似乎没那么严重？

A1：

智能硬件有标准。

A2：

标准归标准，实际情况呢？据我所知，目前的金融行业，也并未做到全字段加密。

A3：

这个问题是集中在终端侧的泄露？

A4：

终端侧文件不落地，只做中转和展示？

A5：

不落地的话就用EMM，给APP加个壳，像银行流水导出现在都是加密和水印的。

A6：

加壳是外围了，类似于WAF这一层，加壳是必然要做的。

A7：

那场景是指哪个？终端侧漏洞被利用拖库？

A8：

如果导出的话，水印，OCR之类的是基本的。

A9：

是的，数据不要直接给。

A10：

这个说的很对，在能不给的前提下，尽量不给，文件不要存储在本地，回连服务器，服务器做结构化加密，至于要不要全做，看你们评估，全做成本太高，而且影响性能，导出文件要做到可溯源。

A11：

比如，手表/手机要做人脸识别，这个目前是存在本地还是云端呢？存在本地的话，按照个人信息来说，那必然是需要加密的了。

A12：

人脸识别从后台拉去校验，你云端肯定好管理，本地端很容易出问题的。

A13：

一般只存摘要。

A14：

按照最小化来说是，但是有些厂家不会这么做的，为了方便分析关联，啥都存。

A15：

最终不落地，但不代表中间环节会留存。

A16：

这个中间留存环节，也是个很大的问题。

A17：

其实也存在一个问题：存云端还是本地，这是目前的两个选择。存在云端本身会扩大安全风险。

A18：

云端。要是我来做肯定不会放在本地，本地风险更大。

A19：

各有优劣势，所以，据我了解，目前两种都有。

A20：

云端一般都会用第三方吧。

A21：

第三方是第三方，但是数据本身的加密、库的加密还是得自己来。同时库本身的查询这块的权限控制审计等等也都要做。

A22：

回到本地数据安全问题上，比如我存人脸信息，以前是存的图片，我现在是不是可以改成通过算法，存特征信息？算法做好封装，独家。

A23：

能不影响你们的业务，我觉得可以的。

A24：

我理解本地端有几个门槛： 1、系统本身，安卓基本把Root关了，ADB也关了； 2、硬件本身就是一道很高的门槛； 3、本地文件加密一道门槛。 所以，我觉得存在本地也不是不可？

A25：

我觉得当你把本地数据存储，虽然加大门槛，加壳，加密，用户没有最高权限，不能调试，但是，你还是要做传输与后台对接，后台也可以与前端进行校验，与其这样，还不如只做后端，防护能力更强。 如果说算法加密，现在基本加密算法，你就算拿天河一号跑都不知道要多久，所以更多出现无外是密钥泄露导致的安全问题。

A26：

可是，检验是在本地做的。

A27：

所以可以做校验啊，毕竟这是用户功能，但是可以类似沙箱一样功能空间，进行完成，主要文件不落本地，但是功能需求和数据还是可以从后台拉取完成校验。

本期观点总结

本期话题讨论了切割WAF时的误报率，虽然大多认为业务对假阳性阻断是零容忍，一般没有硬性的标准，而取决于业务能够承受的拦截和风险程度。在实际操作中，需要进行分析数据、优化策略，并且根据突发流量等情况调整WAF规则。同时建立反馈机制，让业务部门能提供针对WAF改进的反馈和意见。此外，应该逐步将站点切换到防护模式，而不是一下子全部切换，以及申请接入WAF最好是由业务部门主动提出，甚至可以制定一些回退方案来取得业务部门支持。

本期话题还聊到了手机端、手表端本地个人信息的安全措施。在实际操作中，需要根据终端性能问题和复杂交互的业务需求来选择合适的安全措施，如是做到库文件级别还是字段级别，或者同时做到库文件和字段级别。如果终端数据泄露，需要对影响程度进行判断，以便及时采取应对措施。为了保证终端数据的安全，可采取如不落地存储文件、使用EMM给APP加壳、结构化加密等。此外要尽量减少数据直接给出，对数据进行最小化处理。同时针对不同的场景，选择合适的存储方式，以及注意中间环节留存问题，从而确保数据安全。