0x1本周话题
话题：已知某非http的供应链产品存在漏洞，自己在用，并面向互联网提供服务，漏洞利用条件未知。已知这个资产一旦被入侵，必须停业务。大家觉得做到怎样了，才可以不把这个业务停了。
A1：对供应链提安全要求，修复漏洞呗。安全owner业务，要业务推进。
Q：供应链自己不知道有漏洞，0day。
A2：做好应急，及时监测，出现安全问题切到业务备机跑先，主机及时修复了切回来。上报国家，由国家同步供应链，然后自己提前修复。纵深做容忍，应急做预案，重保监测异常。如果有切面，就自己进去补洞。
Q：必须停业务的原因是什么？
A3：重要且核心业务，多活冗余设计，按服务区域或客户等特定条件分类多活部署，接受部分服务能力缺少，同时互为对照组分析备用，攻坚源代码，根据供应链服务商意愿和能力，针对开源协议、源代码知识产权或者第三方托管情况等情况，内部组织源代码走读... 技术增加入口封装，对延迟不敏感的业务，考虑牺牲用户体验换取变相加强纵深防御能力。
A4：网络侧被绕过正常，但是服务器日志、操作记录、进程、用户、网络连接都完全无问题，感觉八成说没被利用吧。
Q：你是怀疑有漏洞，但没证据还是说确认有漏洞？
A5：考虑漏洞产品增加支持异构平台部署+资源多活，保持应用层业务观察。
A6：你就理解是没有具体细节的情报好了，但领导要求自证，安全了吗，够不够。这个背景可以忽略，课题我觉得是通用的，到了演习期间，一样会有这种事。网络连接这一块有麻烦的点，就是这个业务既需要被any访问特定端口，也需要请求any的dns解析，不需要建立tcp。
A7：可不可以把暴露面收一收，入向访问放在VPN里面。
A8：不同供应商与同一供应商不同技术栈都能有利于对照观察。场景如：一个组织内不同的邮件系统，一个产品部署于信创和传统系统都可以考虑。
A9：就以邮件系统为例好了，信创有漏洞，传统暂时没漏洞，部署两套？那岂不是任何一套有漏洞都会被入侵。
A10：是的，客观上肯定增加了风险面和维护量。好的方面是，可改善了关键业务局部连续性服务能力的可能性、可靠性，接受局部服务能力缺失，压降全局服务中断风险，关键业务可以考虑以冗余和复杂性对抗未知风险。大部分产品对技术栈底座会有差异化依赖，这种差异可以考虑。
A11：这个从业务连续性层面没有问题，换个形式，比如被攻击了就一键切换到异构的另一套，也能满足。但假设说coremail或exchange有个漏洞，可以通过精心构造一个smtp协议数据包实现窃取邮件服务器上的数据，这个时候把两套都部署上反而是增加风险了。
A12：我理解你这需求是防范核心供应链未知漏洞。那只能依靠事中，事后了。建立纵深防护，上安全切面，全面安全监控。按照att&ck一个个落实监控，然后验证策略是否有效。
A13：所以主要想考虑，有0day也好，有nday没修也罢，用切面也好，用拟态也罢，那些监测的点，比如函数，比如进程，比如网络，才是关键，哪些点没异常，才能认为这漏洞没利用成功，没有失陷，不需要切换，怎么算全面？这个东西应用好了，是可以对抗网络战的，一开始可能不全面，逐步演进。
A14：你这是要对抗国家级别的黑客攻击，说真心话，有时候还是躺的好，因为攻击都在你的未知区域。先把我们已知的 那类攻击做实，可以发现。
A15：att&ck是攻击技战术，首先防御视角做不到覆盖，其次覆盖的TTP也不代表这个点没问题了，感觉不是好的方法论。
A16：att&ck 不用都全部覆盖，攻击的时候，有时候暴露一点，就可以发现异常。真要防护高水平。像xz后门那样的攻击，太难了。只能等他利用的时候，发现其他痕迹，再追溯。
A17：可以说能发现其他痕迹就是目标。那还是做数基本功。先做到自己紫军，蓝军的攻击都能发现。
A18：这块也每次都能发现问题并改进，蓝军是越来越难了。但蓝军从来不用0day，像此类场景，能显而易见地知道程序内部的调用逻辑监控不到。和自研有很大区别。
A19：精心构造的话，有一定可能性是对特定平台、产品定制化，具体到提及的两个产品，以前学习了阿里有个帖子提到过smtp除了自身安全性低些，在协议组件实现也是有差异的，这种差异可能被利用，反过来也会保持局部有限的服务不受其影响。
A20：异构我理解主要还是解决可用性，保障业务连续性，并不是解决对抗。以前分析Google Beyondcorp构建背后动机时，他们有一个假设是0day是不可能被发现完，然后架构的考虑就变成了，如何在明知可能存在漏洞情况下去进行防护。基于这个假设，Google从http应用层上去构建了统一应用代理网关收敛入口，然后通过实时引擎做基于访问的持续验证。 核心对抗逻辑特征检测作为辅助，核心放在通过可信方式做信任链验证，攻击者构造绕过检测和找0day是相对容易的，但要攻破信任体系成本是很高的。所以对抗就变成信任对抗了，信任体系如果无法攻破，数据包就传递不到真实业务系统上，后来出来创业做持安产品后，这套机制在实战过程中效果是很好的。
A21：http我觉得也比较深入了，就是非http盲区多。我理解异构也能做对抗。
Q：怎么异构？如果是两套同时提供服务，其实是增加了暴露面，漏洞范围变广了。
A22：算是类似拟态的逻辑。比如一类阻断设备部署多个品牌厂商，分别判断一次，如果都通过才算。暴露面不能同时，但内部可以。
A23：这感觉是负载均衡和容灾切换。
A24：其实这也有点问题，类似长尾效应，应用侧0day一类的总是没法完全避免，属于大力飞砖
A25：其实本源上就两件事情 NbSP与OVTP，一个是访问控制边界不被绕过，一个是鉴权链路完备，能做到这两点，后门和0day大部分都是一样防范。拟态能防止一部分的非预期nbsp绕过链路，但对ovtp突破型的攻击防御帮助不大。
Q：我理解nbsp是被动防御，我的设计是良好的，基线是符合的，放着不管，攻击不进来 ovtp更强调主动防御，不相信第一范式一定有效，有没有在尝试，有偏离的迹象，要能发现响应 理念可以融会贯通，我的问题其实是postfix这类没法插桩没法切面怎么可溯， ovtp也漏了咋办？
A26：postfix有源码的，要插桩也没问题。核心问题还是ovtp可塑链路保障难吧，这个以前我们遇到，更麻烦的是exchange。
A27：exchange后来是外面包了一层来做安全增强，不直接对用户。
A28：那我理解所有的都通用了。能插桩的插桩，不能插桩的，让它自己不对外、不出访，外面包能插桩的提供服务，即便这个不插桩的被利用了，也无法回连。
