KD的疯狂实验室

今天参与了一场国际安全厂商组织的交流会议

其中工作之一是打通AWS DNS Firewall 与 Security Hub。当发生威胁事件时，Security Hub能接收到情报通知。三方依赖组件漏洞升级，无论对于哪个公司都是一个挑战性的事情。逐步升级也是对现有产品的一个负责。今天跟部分基础服务开发进行深入沟通，了解了当前升级的挑战，特别是对稳定性的影响。一味的升级，其实在没有架构师规划的情况下，实际并不可控。两者不能直通，需要使用lambda进行触发。2 当前方法未触发风险，但未来可能触发的。就可以按照这个方向逐步升级或规避。

TLS升级不易验，iOS加固易疏忽

默认 method，查询字符串 等会被屏蔽，你在日志中是找不到的。应该是为了隐私安全。启用方式依然是WAF面板配置日志CloudTrail的地方去掉你希望显示的所有共4个✓。采样：每一条WAF规则都会产生一个采样默认。你觉得是一个WAF，如果你有20条规则，到日志里就是20倍的量了。后果是：CloudTrail里数据量会暴增。特别是PutEvent的费用。

显然，这种说法是安全工作中的一个挑战。因为推动时间也蛮长了，做出了：只要升级一部分，易升级的组件即可。前天遇到的挑战是某后端部门排期出现问题，本应该做漏洞提升的时间被其他工作插入。测试团队需要进一步支持，因为组件升级，许可证升级以及后续的编码安全建立都是一串蚂蚱。基础的安全种子显然已经埋下。团队有人A提出，是否有必要按照某软件报的漏洞信息实施安全提升工作。我们的信息安全策略就是通过覆盖三防组件风险，降低我们产品自身的风险。特别是搬出来A之前在，其他企业的经验，即。安全宣讲和必要的沟通是无法回避的。

提项目延宕已久，从去年帮助其识别出该风险后，去年年底已经出了解决方案，比较漂亮的解决了该问题，特点是不需要客户端升级服务器升级就能完美切换。结果呢，最近项目方说服务器成功之后，还需要一个月时间。而且一个月还不能保证迁出。该项目是一个比较常规的安全要求，属于国外省ZF这种。解决：详细跟他们盘了一下他们的方案。发现他们竟然忘记了我去年年底设计的方案😭。这个是今天的主业，该项目出了相关安全要求文件为我们。只能跟他们复盘了一下，当时我的解决方法，项目方恍然大悟😎。关键点：方案实施出现不合理的时间。

包括它有没有公开的漏洞，它选用的依赖是否有缺陷，它的开发者是否活跃，相关组件维护成本，如果应急维护的话，是否有人掌握相关技能？预期有问题的主要是非常陈旧的设备，早期陈旧定制设备上的应用程序，可能不支持https，还有一些日志上传端口。跟开发梳理应用的上下游工作逻辑是非常有用的，发现根本不需要使用引用短链接组件，使用下游服务就能解决问题。目前在项目经理的助推下，各产品线都在排查自己的域名是否支持https，把成年老域名都给找出来了。此外，对于一些管理页面，也应当做到内网保护，也就是外网不能访问相关路径。

此外，还有一个挑战就是当安卓更新新版本的时候，我们需要follow这样才能保证我们的APP产品可以在新版google中兼容性最佳。当然，我这里还认为这种TOP1000这种兼容性测试应该由加固厂家进行，而不是让每个客户自己去测试。Y加固在aab格式上兼容性存在问题，特定机型会崩溃，厂家是以修复引擎的方式进行更新解决。我们这边的解决方案就是增加云测，但是国外的用车没有支持相关的自动化，需要进一步的开发。开发相关同学建议更换加固产品，但这并不能解决根本问题，即：无法验证兼容性的问题。经过基本的打探和初步试用。

主要发现了一些奇奇怪怪的问题，比如扫描到会把一个小端口，暴露出去。2 增加日志留存时间，捕获这种测试团队导致的事件，较短的WAF留存会导致难以识别出这种激增的情况。原因是我们设防的服务器是a服务器，它跟b服务器进行通信，而b服务器又直接跟a服务器进行通信。主要是在迁移某waf到测试环境的时候，测试团队很快就有反应了，发现了大面积的故障事件。这里面的主要的风险问题是有一些非常老旧的产品只支持http连接，这种都需要排查出来。所以有继续推进此事，通过拉起会议的方式，基本现在主责人通过一个项目的方式在推进。