摘要：各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第252期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第252期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。

话题抢先看

1、漏扫设备会将一些的特殊漏洞也写到报告之中，比如信息项（如：SSL使用了自签证书）、仅靠版本识别（如：Oracle仅有编号漏洞），这些漏洞不属于威胁项，互联网上也没有公开利用案例，对于这些漏洞有什么处理方案？

2、日常遇到的理论上不可利用漏洞的处置。比如一些非默认配置漏洞，这种漏洞触发条件苛刻但影响范围大，该如何处理？

3、最近数据安全事件频发，尤其是百度事件。大家对于“开盒”是怎么看的，自己有没有什么防护方法？

Q：漏扫设备会将一些的特殊漏洞也写到报告之中，比如信息项（如：SSL使用了自签证书）、仅靠版本识别（如：Oracle仅有编号漏洞），这些漏洞不属于威胁项，互联网上也没有公开利用案例，对于这些漏洞有什么处理方案？

A1：

我们一般是发送原始报告，对于有疑义的进行人工核验。

A2：

扫描之前剔除这些无效漏洞检测项，就不会出现在报告里了。

问到点了，前几天刚处理的，我是不认可并且直接让对方把这个洞在报告里删了。

A4：

使用访问强控缓解，只允许白名单访问。

A5：

心理上会说on9，行动上可以让加白，只要没有实际危害，有危害也可以靠CVSS有控制压一压。

A6：

内网里边SSL证书漏洞一般都忽略，公网必须使用签名证书。

A7：

忽略，做好备注或记录留存（这个只是分锅的时候用得到，或者说保护自己）

或内部讨论定个结论。（大部分情况下是风险接受）

A8：

确认无风险，改版本号；确认有风险，升级版本。

A9：

修改版本号隐藏版本号，很多都是根据版本号判断，并未验证实际情况，以可利用为主。

用的某厂商漏扫，直接配置扫描模板，按需扫描漏洞。

A11：

漏扫设备的报告也不是直接使用吧，需要忽略或者风险接受的漏洞信息不在最终反馈的报告里呈现。

A12：

所以我们不用主要用商业漏扫，商业漏扫最多做自己扫描器的补充和召回。

A13：

分为三个部分考虑，人、产品、服务器。

人主动忽略；

产品排除该漏洞；

服务删除响应内容中的版本号。

A14：

参考下别人的处理方案，忽略还是豁免还是误报；直接用自带的自动更新修掉算了，除非高危或者严重再处理。

闲着没事儿的话随手改掉，好多情况下就是配置文件加个注释的事儿。

A16：

稍微核实下，看是什么信息项，只要不是敏感信息就忽略；Oracle这种一般都是风控，在运的不敢验证。

A17：

甲方就让厂商出具分级表，哪些需要关注一下，哪些直接pass，但是厂商一般都糊弄，所以......

A18：

这个看自己所在公司的安全管控力度，如果对于这类信息级的需要修复，那么就需要按照要求来，如果没有特别严格的要求，根据业务实际能力进行安全整改，或者先不修复。

漏洞利用条件苛刻+修复成本高=忽略漏洞

A20：

还有是否可以用不改系统的情况下修复，比如WAF上配置下规则，不让他扫到。

A21：

如果是自己公司扫描的，确认后直接忽律；

如果是其他公司扫描出来上报上来，不好意思，麻烦提供一下利用证明，谁提出谁举证。

A22：

漏扫是漏扫，漏扫也有误报率，正常漏扫后验证一边才能给出最终的报告，你都不验证，漏扫说什么是什么。

A23：

上级单位扫描到了，才不管能不能利用呢，只要漏扫扫出来的，就必须处置，还通报呢。

A24：

+1 碰到过，就写说明，然后内部屏蔽掉。

要是领导对风控的逻辑不太理解，就得跟乙方说要隐藏一下吧？

A26：

说明上级单位没人懂安全，全是被乙方忽悠的。

A27：

就是因为现在的监管支撑单位扫不出问题，就把这些当严重、高危，写到报告里。

A28：

一般我这边是，如果对方配合，我就把报告里面能利用的挑出来，让他们改了，剩下的尽可能修复；

如果不配合，那我就他们全改。

A29：

之前开发操作系统的时候被一个漏洞搞了几个月，极光每次都能扫出来。客户非要我们修。要不就不采购，但是官方不出补丁，我们也不允许自己改版本。

A30：

这个群里有个老哥好像发过，某地网安TLS版本低也通报了，真实事件。

还有没有配http头。

A31：

漏扫给安服洞和垃圾洞的，以后还合作干嘛。

A32：

这种漏洞基本是乙方报告里没漏的的时候给甲方凑数交差用的，不然大家都尴尬，你可以忽略，但是必须得让报告里有。

A33：

很多测评机构只会带个设备扫描，然后出报告，也不会验证，设备给什么就出什么，设备规则也是人写的，就像你WAF出告警，难道每一条都是真实攻击吗？那还不是得要检测研判来判断是否是真实攻击，一个道理。

A34：

可以参考CVSS打分。

A35：

一般分最近缺kpi和最近不缺kpi两种情况处理。

A36：

忽略。漏洞不修都不挨打的，更别说理论上不可利用的。

A37：

最近那个Tomcat感觉闹麻了。印象中好像很难利用的，但各个厂商都在卷复现，GitHub上利用脚本一大堆。

A38：

您是否在找：CVE-2025-24813。

A39：

修，不排除后期有些开发会瞎配置。

A40：

A41：

没启用相关服务，降低风险，排期再修。只要他存在并且能被复现出来并且能被产生危害，我就会让开发修。

A42：

1、理论上不可利用，提出漏洞交于上级+业务侧评估，是否接受该风险

2、排期修复

A43：

触发条件苛刻就用原理扫描，扫出来还是修。

A44：

用缓解措施代替漏洞修复，缓解，就是用防火墙把扫描器黑名单，或者直接上Filter。

加固，通过限制访问方式进行加固，然后不用管，前提是没有升级条件。

A47：

已经非默认配置漏洞了, 其实有时候加固建议也是修改这些配置。

A48：

有一些建议修改可能会导致服务出现异常，所以一般都是限制访问方式就好了。

只要不是直接对外提供服务的都可以这样。

A49：

其实可以把注意力放在更宏观层面的方法解决问题，比如模块化部署等，不一定就非看这个问题修不修，以微观问题引导宏观建设，以宏观建设修复微观问题。

A50：

往大了讲，每一个工作一个工单开展都是要成本的，实施收益要大于实施成本才行，如果这种洞利用成本极高，危害也就一般般，那肯定得忽略了。

A51：

你怎么估算的这个威胁，特别如何动态更新利用成本？

A52：

以风险评估的思维处理安全漏洞，要参考威胁发生可能性，漏洞利用难度以及资产重要性来排优先级的。如何评估，怎么动态更新是一个问题；如果明确知道利用难度极大门槛高，漏洞危害也一般般的话，这种确实就是风险低的。

A53：

这个是真忽略，遇到严重的话只能保留证据去报警了。

A54：

这个是泄露方的问题，但是泄露方又不承认，所以是无解。

大家都裸奔=无影响

A56：

今年315曝光的，现在SGK都产业化；直接做个系统， 把数据导进去，你在里面能查到一个人的职业、姓名、年龄、爱好，有什么需求，经济能力，名下资产······

A57：

我记得很久以前某东泄露那次，他们还有高管发消息说是撞库，问题是那次我泄露的密码是撞不出来的。

A58：

暴露姓名、手机号或者身份证号码其中一个被开盒基本上百分百，除非名字大众。只能在注册软件的时候用不常用的手机号、能不提供个人信息就不提供。但是很多软件都要求实名注册，实名注册了又保护不了客户信息。

A59：

即使你不上网，一样信息会泄漏，被动泄漏，所以普通人不用防，该吃吃该喝喝，除非哪个系统里都没你的信息。开盒是一把双刃剑，用在对的地方，可以抓骗子、抓老赖。

A60：

没脸看，一方面保护个人信息，一方面监管要求获个人信息。用公权力为私权利谋取合法信息必然导致私权利违法使用个人信息。个人防不住，除非销户移民隐居山林，自给自足。

A61：

现阶段的数据安全都是为未来的人铺路，我们这一代年轻人，早就泄漏得底裤都不剩了，身份证号码、住址都很难定义敏感信息了。

A62：

说实话，交出去就当作没有了 其实作为个人来讲真的无可避免。2013年交出第一个电话给Dell，我收了10年的销售邮件和电话骚扰，至今还在。天天邀请我Dell会务组参加会议，骂也骂过，没用，只好接起来，摁掉。

A63：

制度、审计、访问控制，该做的基础工作做做好。

A64：

一般做风控监测 ，纳入风险隐患清单跟进。把不用的网络平台全部用假信息更新，但是有些实在没办法，你懂的。

A65：

百度的问题其实是PR问题、主要是在于公关、让业外人士知道企业安全控制的严格、虽然实操都草台班子、但这事一看就知道肯定是盘外招、一个副总裁不可能这么空、还有一批从上到下敢集体触发风控的手下、数据安全说到底主要就是流程控制落实到位。

A66：

少去触发冲突，能避免99%的开盒。

A67：

以前看过一个针对这个的防御手法，可以给自己做一套假身份，然后通过各种信息混淆去偏转开盒方向。

A68：

“开盒”泄露他人隐私，还需要通过监管机构和政府单位来管控，加强监管和处罚力度；对于个人，不要随意注册网站，不要想他人透露自己隐私信息，快递单不留真实姓名。

A69：

注册网站这个其实已经没办法了。我QQ都注册十几快二十年了，互联网上到处都是痕迹。库里一查跟裸奔一样。

A70：

1. 抛弃所有的互联网账号

2. 重新建立必要的服务账号

3. 加强自身的信息管理

4. 使用密码管理器，做好账号（信息）分离工作

but，能做到的人不多

A71：

这个问题一直问自己。既然当前这些数据都泄露了，那我们从事这个行业，除了混口饭吃，还有啥意义。从这几年来看，整体大形势还是向着好的方向去的，通过一代人的努力，至少可以保证下一代人的数据安全性。

A72：

监管还是比较难，例如游戏需要实名制，目前只是输入身份证和姓名即可，虽说是由国家认证平台认证，但能确保游戏厂商不会偷偷自己不留一份呢？同理人脸识别功能；还有就是手机APP的，特别安卓系统，不给权限就不给用APP，这个我从以前就觉得特别恶心。有时候用个壁纸软件非要读取我通讯录和短信权限，不给权限就不给用

我现在能做的就是数据混淆，能不实名的不实名，地址姓名能瞎填的瞎填，电话营销来了问是否某某先生，就说不是，号码新买的；问我是不是办理了什么就装傻，没有，谁冒用我身份，你们赔钱不。

在日常安全运营中，漏扫设备常将非威胁性漏洞纳入报告，引发处理难题。行业内对此存在多种策略：有人主张人工核验或通过扫描模板过滤无效项，也有观点认为应直接忽略或修改版本号隐藏信息，甚至通过 WAF规则拦截检测。部分企业会依据 CVSS 评分或内部风险评估决定是否修复，而面对上级强制要求整改的情况，通常采取写说明或内部屏蔽的方式应对。

对于理论上不可利用但影响范围大的非默认配置漏洞，多数人选择忽略或通过访问控制、防火墙限制等缓解措施替代修复，少数建议动态评估风险并优先处理有 POC 的漏洞。

数据安全事件频发背景下，“开盒” 现象暴露了个人信息泄露的严峻现实，行业普遍认为个人防护需减少敏感信息暴露、使用假身份混淆数据，而企业层面应加强访问控制与流程审计，但由于数据泄露渠道复杂、黑灰产技术专业化，彻底防护仍面临挑战。当前数据安全治理呈现被动防御状态，需多方协同推进制度完善与技术创新。

Q：关于企业网络安全审批流程的建立，各位在甲方从事信息安全工作的师傅，有没有遇到需要建立信息安全审批流的场景？一般哪些场景需要有审批流，都会经过哪些关键人员进行审批，审批的目的是什么？

A1：

好问题，这个还真的接触过，感觉应用安全、安全运营、办公安全、安全管理各个方向都需要建立审批流程。类似应用安全，漏洞工单应该可以通过OA流程参与评审，漏洞延期也可以，这样可以做到留痕审计。数据安全类的敏感数据提取，我觉得也应该走流程。师傅们还有别的场景没，参考下。

A2：

网络安全看等保的审批要求，按三级来做。数据安全的，一般10万个人信息处理可以审批、重要数据要审批、数据共享交换公开出境跨境要审批。

A3：

最多的应该就是在SDL流程中了，审批系统上线确定是否需要做上线前的测试，已经测试出来的漏洞是否已经完成整改。

A4：

涉及到漏洞管理制度以及网络安全事件应急处置等场景需要进行审批，审批一方面是对事件处置记录留痕，一方面也是体现专业性和规范性；事件处置涉及到关键人员包括信息安全部主管领导、 IT相关负责人、业务方主要负责人以及上级领导。

A5：

我们归到大类OA变更流程申请。细项有：访问权限控制、黑白名单处理，端口策略，外网权限啥的，一般是业务或者技术人员需要，然后进行提单，操作人进行一级评估，然后操作人直属领导过，提单人员直属领导过，最后回到操作人操作，确认，提单人确认确认，归档。

但是假如网络权限、或者安全业务的变更，需要外部支撑处理，特别是需要盖公章处理的操作变更操作，会经过总经理。内部动作，基本就是 直属领导这级别就可以了。

A7：

涉及互联网暴露面的相关内容
例如：互联网NAT映射、直接为设备配置互联网IP、DNS域名、VPN和4A通行字等内容的全生命周期管理，按照谁主管谁负责，除了发起部门以外，流程中涉及的所有设备、系统管理的部门领导（中层副职或者正职领导）都要审批。不走流程就是各种放飞自我，只管业务能通、能用，别的啥都不管了，极端情况是个新手菜鸟黑客撞大运都能黑进来。

同时也是为了留痕，有些事情虽然合规，但是因为一些客观的意想不到的原因导致不良后果，有些人就会甩锅，特别是需求方甩锅，为了避免甩锅，需要留痕。

留痕也是要严谨，流程里面要写清楚操作的具体内容，而不是一个很笼统的需求，操作人员按流程的具体要求来配置。

去年有个部门拿了个单子，说让社会xx公司加入ACL白名单，访问我们业务支撑系统在互联网的一个接口，我说，你要写清楚对面IP，我方IP和端口。
那人说，部门的某某知道的，他会配（好像是NF里面有IP备注）
我说，不行，单子要写清楚。那人就认为我是在刁难，复杂化流程。

跟他解释了半天，无语了，他跟我一个大部门的，事情是市场部门发起的需求，他不怕出事了我们两个一起背锅么？

最后巨搞笑，业务支撑中心不签字，他们说，这个操作不是业务支撑中心做，我们不担责，但是我们不签字不表示我们反对，请发起方承诺，出问题他们担责，然后技术部门签字，就可以操作了。

Q：各位大佬，有听说过EuroPrivacy么，这个是针对GDRP的认证么，中国的企业在海外有业务想不受GDRP的影响做这个有用么？

A1：

有用，但用处不大，没有官方认证但是有第三方认证，可以协助你们在声明中标注你们符合GDPR要求及通过了EP认证。

A2：

现在应该没有所谓的官方认证的吧，感觉这个是不是有点像27701之类的。

我在网上收了下"数据控制者和处理者都有资格申请 Europrivacy 认证。Europrivacy 认证可以在任何地方用于评估对 GDPR 的遵守情况，但证书的发放不适用于没有为数据主体的权利和自由提供充分保障的司法管辖区。"中国的企业应该不满足充分性条件吧，那做了不是也白做？

A3：

没用，GDPR是管理条例，这些机构的声明并没有豁免作用。认证只能是用来甲方审核你是否符合要求的时候，如果有个知名的认证，比你准备一大堆材料要有说服力，但是最终别人想怎么审，还是看人拿捏。

A4：

简单举例，就类似你做了ISO 27001你能说你满足ISO所有的控制项吗，你只能说你通过，且ISO可以作为和客户沟通的背书而已，但并不代表你完全完全满足ISO 27001所有要求。

这个也有两三年了，SGS这些都可以做。类似这种认证都不是标准，还是背书而已，在大家都不信任的时候，推出第三方认证，好达成一个默契而已，除非是CE这种强制的，不做不给进市场，那就不一样了。

Q：近期个人信息泄露事件在网上传的也比较热闹，在思考一个问题，如果企业卷入隐私泄露风波，需要快速自证清白。大厂还好，不论是技术层面、管理层面还是安全投入都比较多。但对于2～3人小团队，安全防护的不管技术层面还是管理流程，业务场景都不能完全覆盖，并且安全投入很少，这种情况下在没法完全的自证清白或者不具备自证清白的能力。

想请教下大家两个问题，大家有没有好的想法或建议：
1、对于上述情况，小团队如何自证清白。
2、这个情况怎么和老板沟通，一起结合这个场景评估ROI，定一个基础线，如我们做到什么程度可以；哪些场景的自证清白可以少投入或没法自证清白也接收风险。

A1：

已经产生危机的情况下， 你怎么说你自己做的好， 自己无辜都没用，所以是自证陷阱，本质是信任危机。

A2：

不好搞，比如数据源头是你这里，但是是合作方或者监管方泄露的，怎么查，甚至有可能是一个正规涉密渠道给了别人，别人泄露了，除非是沿着黑灰产那条线一路倒查。

A3：

把日志弄全就行，GA也是基于日志来进行取证的，你把数据库、应用、主机这些日志弄全，可以搞个openrestry，把防护日志也开着，最后加个jumpserver，保证所有日志大于6个月基本就可以了。

A4：

小团队就不要收集任何个人信息了。我们从GDPR开始被毒打，之后的原则就是避免收集个人信息。一牵扯到个人信息，无论是境外，境外，还是出境。都费劲。小团队完全搞不定，所以干脆别收集了。

A5：

都是小团队了，大概率很难拿到预算，如果业务强相关，那肯定以合规来驱动建设。小团队，小公司，没到要做危机PR的地步。泄露就泄露了，系统能用就行。

A6：

首先自证清白这个事情，不是安全干的活儿，理论上是品宣部门或者公关部门出面，技术人员最多是帮忙通过技术手段证明和公司没关系，或者关系不大。

其次，从历史上多家数据泄露公关文来看，如果真的泄露和贵司相关，与其遮遮掩掩，不如大大方方承认，并且承诺，贴补，一定程度上可以降低舆论长期发酵对公司名誉品牌产生更长时间的影响。

再者如果和你们公司没关，最好的方式是沉默，不予回复，内部提前自查，确定是不是你们，如果舆论导致监管找你们，你们只要配合监管自查给出不是你们的证明报告就好。

最后，接着舆论风波，找老板说一下事情的严重性，如果老板愿意投入，你就能刷一波存在感，并且定个红线出来，老板觉得没卵用，那你就该干啥干啥。

光看不过瘾？想要加入话题深入交流？

那就来FreeBuf知识大陆电台小程序

网安人的“小绿书”

找报告、搜文档
行业新闻 、经验分享、职场八卦、同行互动

AI变声和匿名功能

专为社恐人士打造

让大家以更轻松的姿态

随时随地，想聊就聊

我们已经邀请数位网安行业大牛开设电台房间

“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1300+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。

来源：FreeBuf