高危漏洞下的业务安全、公有云数据泄露的责任划分 | FB甲方群话题讨论

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

注：上期精彩内容请点击：谈数据泄露、勒索和云故障

本期话题抢先看

1.收到的漏洞是否立即评估和通报？会有分级通报的流程吗？若要修补的高危漏洞所涉及的业务不能中断或停止，业务安全该如何保障？

2.公有云上的数据出现泄露，责任归属一般该如何划分？如果责任共担，但万一平台方推诿，有没有什么解决办法？

3.为了不被监管驻场成功通报，哪些是公网业务上线前要求检查和注意的事项。尤其是开发经常性的坏习惯？

4.年终盘点：关于今年出现的新技术或新服务，以及来年安全预算的探讨。

话题一

对于收到的漏洞是不是立即评估和通报？会有分级通报的流程吗？

A1：

我们是先评估，再通报。

A2：

我是立即通报，我能修复的我就安排修复，需要研发配合的就通知到研发，让他们排时间修，如果能WAF缓解就先WAF缓解。修复后的情况让研发自己解决。

A3：

取决于漏洞来源，SRC就搞评估分级，然后下发漏洞。监管漏洞直接复现，成功就通报。

A4：

我们一般是按漏洞分级，分级后进行处理，只通报高中风险的漏洞。

Q：如果漏洞高危，涉及的业务不能够中断或停止，应该如何保障业务安全？修复后如何确保业务兼容和稳定？

A5：

加强防护检测，优化监控策略，先在测试环境进行修复，然后在发布环境修复，在切换到正式环境，做好备份、还原点。

A6：

漏洞高危，业务又不能断。其实取决于公司对风险的接收程度。 一般收到漏洞，会做漏洞评估和分级。这个分级是看漏洞对业务的影响不是漏洞本身的影响评级的。一般高危的要做两种解决方案，临时跟永久。修复方法取决于业务数据，时机就是监控看到的业务最闲的时候，兼容性一般都是测试环境测好评估好再上线的。

A7：

我觉得还是取决于业务本身。如果漏洞无法修复，或者官网暂时没有解决方案，一般有两种途径：一从漏洞引起原因入手，看看能否找到临时规避方案，比如业务暂时不对外提供服务或者白名单，减少攻击面；二、寻找替代方案。

A8：

无法修复就看是哪种情况了，比如利用条件是访问网站的某个目录啥的，可以不修复网站本身的漏洞，NGINX容器加目录黑名单，直接404屏蔽。

A9：

比如像是旧的设备，无维护商，这种就不指望修复了，可以放在内网安全防护体系中再用，择期退役。

A10：

其实哪怕紧急修复也肯定有一个保守方案，比如冗余的只升一台做稳定性测试，但是风险在于，上次被监管扫到了，不接受解释。

A11：

如果漏洞高危，但是业务不能停的情况，我们就会进入评估程序，评估漏洞目前是否受到影响，是否出现数据泄露，是否影响主流程，是否有危害，如果危害较低，或者没有实际可验证的风险，我们会延长修复时间，如果已经危害到主流程，我们会通知CIO，会同CIO和业务负责人做热更新。 如果漏洞高危且无法修复，目前明面上的做法是，关闭业务或者切换业务，实际的做法是，前端增加访问规则，让漏洞无法直接呈现。

A12：

可以先上些临时措施，如零信任网关开通策略，开启严格的访问控制策略，如果源地址可以限制的开通白名单，不能限制的加强安全监测做好自动封堵。同时也重点监测应用层防护，提高防遍历爆破监测要求。尽量做到早发现早处置。修复后，可以开展灰度测试先行验证兼容性及稳定性。

A13：

这比直接修复还难。

A14：

是要有其他防线辅助的，单独的防线高危漏洞不修复就不能成为高危了。

话题二

对于公有云上的数据出现泄露，责任归属一般该如何划分？有说是责任共担，但万一平台方推诿，有没有什么解决办法？

A1：

这看情况： 1、如果是云平台本身产品的漏洞或缺陷导致数据泄漏，那理应由云平台承担； 2、如果是自己管理不善，没有采取必要的防护措施导致数据泄漏，那就和云平台无关。

A2：

数据泄露这事，看从哪里泄露的，是通过什么路子泄露出去的，如果说是安全产品/云厂商提供的实例本身问题，那云厂商自己担责无可厚非；但如果说是业务漏洞/数据库密码遗漏了这类，那怎么着都怪不到云厂商。

A3：

我们刚编制了一个云安全管理规定，里面有一张图，是讲IaaS、PaaS、SaaS等不同服务的责任共担划分的，很清楚的。

A4：

这个东西其实要分开看。以前在做云的时候认为责任共担更合理。因为数据分析后大部分都是客户要索赔的。后来做客户的时候出问题也可以直接找云解决的。为了应付客户一般的云厂商都会推出一个类似责任共担的模型出来。 平台方推诿我觉得可能性低，至少大的厂商口碑会更加重要。如果推诿责任共担模型、最近推出的数据安全法等也可以用出来。至于怎么用，要看自己想要什么样的结果。

A5：

如果签了数据安全协议、数据保护协议，可以找平台索赔；如果你没签相关合同协议，只能自己认，如果有签署，可以报案。 还有一种情况就是公有云平台在隐私政策，或者其它条款里提到了不担责，你还是选择了接受，也是自己承担。不过也有特殊情况，公有云平台给你推荐了一堆安全措施，你没有用，责任自负，但是没有说明这些措施的必要性，责任归平台；另外你可以要求平台提供等保、云安全、云合规的测评报告，如果不能提供或者不满足，责任归平台（黑平台）。

A6：

主要还是看哪一级的事件，有公属性的泄露，会有相关部门介入理清各方责任，最关键的是等保要做，这是应尽责任。

A7：

不全是，还有双方是否明确约定，如果明确约定了 平台也有可能不受影响。

A8:

上海今年的事件就是除了数据所有者自身外，其他各方、包括云商、测评方全部兜进。

A9:

上海那个特殊，它是关基，选择二级供应商违规了。 违规1：关基原则上不能选择公有云； 违规2：应急选择公有云也可以，做好供应商资格审核、能力审核也可以，上海那个就是关系户，两个都违规； 违规3：应急选择公有云，需要向监管部门、用户上报，并加强管理和监督； 违规4：条件恢复后应该从公有云撤下来，没撤； 违规5：就算应急使用公有云，也需要单独的物理资源、分区、单独的网络环境、计算环境、存储环境甚至支撑环境，如运营商线路、IP地址、DNS等，要和普通用户分开，包括做好路由屏蔽、访问控制、攻击面隐藏等措施，也包括访问源控制，不能让无关来源访问； 违规6：没有应急预案，没有进行数据处理如脱敏、去标识化。

A10：

一、按云类型： 1、SaaS，用户除了和账户管理相关的，其他锅都是云服务商的了。 2、IaaS、PaaS，真要责任共担了。 二、平台方推诿确实不容易，特别是遇到大平台的时候，要去审计大平台都难，别说推诿甩锅了。只能一边走司法一边换平台。

A11：

平台推诿，那也可以打官司让法官定，这个我觉得不是问题，就算耍赖皮，名声变差了毁的是将来的生意。 责任共担模型，边界划得很清楚的。数据泄露一般肯定都是客户自己承担，除非是因为平台的BUG或者功能缺陷，以及平台泄露客户密钥导致的泄露。

A12：

客户也很难知道是不是平台的问题吧。

A13：

这个很好判断，就你一家，那就是你的问题。如果多家都有问题，那么可以考虑怀疑平台的。 极端点的话，如果甲方非常关注数据安全的，那么上乙方平台的数据都是加密过的，就算乙方不小心给你泄露了，也不会造成什么损失。重要数据不加密，这个等保也不会让你过吧。 甲方的责任不可能无限制的往乙方身上推，毕竟我们也可以说就是因为乙方服务不到位，没有提醒我应该这么做，导致了这次泄露。这样对乙方也不公平，责任共担其实就是一个权限边界，如果乙方承担无限责任，那么他们就得拥有无限的权力。 划清楚这个边界，有助于大家合作，一方面甲乙双方权责清楚，双方不用相互甩锅，另外也不用花太多心思提防对方。 所以其实公有云，不太适合做太细致的安全产品，AWS的安全产品其实就做的不太深，因为责任共担模型一出，它过问客户的数据就不太合适，很多比较深入的一些安全产品AWS就不太方便做。做了你就是侵入客户的空间，这个很忌讳的。

A14：

太细致的安全产品都开始搞自己的云了吧。

A15：

不会的，他们可以在云上卖产品。这是两层信任的问题，因为云厂商有我们所有的数据和权限，这个不信任感是很强的，他们必须从立场上就不能碰任何客户的数据以增强信任。 引入第三方的安全合作商，他们并没有我们账号和数据的所有权限，这个是可控的。所以很多东西你如果做成云厂商，客户反而就不太敢用你的了，云厂商必须要做出取舍来，什么都做反而会失去信任。

话题三

为了不被监管驻场成功通报，哪些是公网业务上线前要求检查和注意的事项尤其是开发经常的坏习惯？做等保除外，这个会做，但一些点等保也检查不到。

A1：

监管都是按照法律法规做事吧，你这里只讲了等保，数据安全的那些也要注意。

A2：

从黑盒方面切入呢，应对监管驻场的渗透？

A3：

给驻厂安排好一切，你懂的。

A4：

让驻场的公司成为贵司的乙方，签个合同。

A5：

驻场多了，除非把前四都招进来。

A6：

大条道理：首先项目预算上年定好的，其次招标公告，评审环节等等均按照国家/央企/国企招标流程进行，按照公司流程进行。不应把两件事看成某种必然联系，若有所指控或怀疑，可以提出，我们将按照XXXX管理办法，多少日内给出答复。前四要一个就够了，试题都是同一套的。

A7：

禁止滥用域名，禁止范域名解析，禁止三四级单位使用上级单位的图标AI及名称。发现很多三四级单位特别爱用集团标志+形象+命名给自己几十人的临时业务，这类东西特别容易被通报。还有就是有些三四级单位会找过来用集团三四级域名，要求通配符解析，也容易被通报。

话题四

年终盘点：前两天鸟哥发布了一篇《2022年安全架构总结以及2023安全方向展望》总结了今年出现的一些创新发展或技术，如端到端身份防御架构落地、全程票据、云上隐私融入设计（PbD）等。 那么，今年大家在安全领域里有哪些进步或升级？采用了哪些新技术或服务，效果如何，或者有哪些槽点？

A1:

做了超融合终端，全策略开启只占系统资源1%。

A2：

给邮箱全线起了Spf、Dkim和Dmarc认证。

A3：

MSS SaaS算是很具有市场竞争力的，尤其是集成化比较好的产品，核心就是掏钱的少掏钱，成本的搞分摊。

A4：

今年搞了几次HVV，被SXF的设备坑爆了。

A5：

啥设备？VPN？

A6：

态感、WAF、NIPS。

A7：

态感听说要他们的人调试完才会好一点，我自己拿来POC的时候上去三天，三天都是误报。

A8：

态感只能算半流量设备，无法判断被打漏洞，被上马后才报连马了，只能人工分析，然后发现，流量也是不全的，很多访问记录，只有五元组。

A9：

我这是产线经理过来给调的，表现还行，目前发现问题了。

A10：

我感觉不是调的问题，我用过很多家的态感，就他们的日志记录做的最差，对安全来说，只有五元组，没有Payload，很难做分析的。

A11：

没有Payload，你们是怎么下单的？

A12：

是的，那还不如防火墙呢，现在一般都会考虑全流量吧，还能看原始流量。现在单单纯态势，买点太少了。

A13：

是的，基本都支持全流量，后面在和他们产线掰扯的时候，说底层定义的，即使用户开了全流量，还是只有五元组。我们最大的影响就是被供应商坑了，做规划的时候光闸没有考虑前后置机，后面再追加，又要放到明年的预算里。

Q：说到预算，看到近期思科发布《我的场所，我的设备：混合办公下的新网络安全挑战》研究报告，96%中国安全主管预计将在2023年将网络安全预算增加10%以上，真会这样吗？

A14：

多数企业安全预算增加都只挂在嘴上说说。

A15:

这种报告抽样了多少中小企业不知道啊，好比新加坡说99.6%都是轻症和无症状，但人家标准是不吸氧都算轻症。

A16：

安全真的很难说服领导加预算，没产出，而且很多单位一把手根本不管安全，只管业务。

A17：

其实现在的趋势，预算或多或少可能还是会增加，但是要达到10%以上真不好说。其实安全增加预算，主要是要拿来增强监测能力与反应能力，来更加适应当前复杂多变的网络大环境，而不单单是零散的增加设备，要呈体系化方向去建设。

FreeBuf 观点总结

不难看出，当企业面对安全漏洞，有时需要依据漏洞的实际情况来决定评估和通报的具体流程，对于涉及高危漏洞但又不能中断的业务，要在评估的基础上制定解决方案，可以先在测试环境中修复，无异常后再切到正式环境，对一时难以解决的漏洞要做好临时应急或替代方案。

对于公有云出现数据泄露时的责任划分，需要根据云的不同类型，如SaaS、IaaS、PaaS等来划分，在明确了责任共担的类型中，若已排除是自身管理不善或没有采取必要的防护措施导致数据泄露，面对平台方的推诿，可善用数据安全法或通过司法途径来维护自身权益。

在年度总结中，大家或多或少提到了今年所运用的一些新技术，但工作中碰到的槽点同样引人关注，看来人和设备有时仍需要不断磨合，不断发现问题、解决问题。在聊到来年的安全预算时，大家对于“年年喊涨”的预算似乎缺乏落实的信心，需要企业充分从自身安全建设痛点出发，制定科学有效的预算增长点。

本期话题讨论到此结束啦~