常态化HVV有哪些特性，该如何应对

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

话题抢先看

1. 今年的常态化跟以往会有哪些明显不同？需要更注重哪些方面的防护？

2. 某些应用系统经常爆发0Day漏洞，因其已经购买和使用较久，目前版本过低，厂商已经不维护了，但如果要升级，需要较高的费用，企业没有预算。常态化攻防下，无法直接拔网线了，大家有什么防护的方法建议？

3. 常态化后，攻击者有更多的时间收集信息和隐蔽潜伏，要如何更好地发现和整改？

4. 对HVV的一些看法。

 话题 

今年的常态化跟以往会有哪些明显不同？需要更注重哪些方面的防护？

A1：

我们还是收紧暴露面，HW前搞一波互联网风险排查，状态依然是外紧内松。听说今年要重点打供应链。

A2：

供应链年年搞，就看搞的深不深，再探握着多少0Day。

A3：

技术发展与使用带来了变化，AI用得更多了，这部分带来了新的风险。无论是通用领域还是垂直领域，都要选择合适的供应商，并对部署方式、提问的信息和数据做好管理。主要还是人员的安全意识教育和可以提问的内容。

A4：

我们的常态化安全基本没什么变化，把ISO27001推向地方、自己折腾攻防演练、普适性安全意识宣导，再搞搞数据安全，一个人也就只能干这些活了。

A5：

今年AI进入我们生活的方方面面，要注意AI尤其是数据安全的防护。

A6 :

常态化我感觉要借助SOAR等自动化辅助决策和处置，当然，真常态化后=没有常态化。

A7：

我们是常态化运营，没有常态化攻防，成本太高了，就常态化运营已经要求了7*24，还没给运维人员安排，感觉没有太大的必要，晚上耗个人在那干嘛，出问题了也联系不了员工处理。早上来了第二天把日志巡检到位就行了。
要说今年攻防的话，我们已经组织过集团内部攻防演练，比以往的确有区别，一个是加入了沙盘推演环节，据说也是去年国护开始就搞的，其实就是辩论赛，大家展示一下。另外一个是对勒索又提起重视，引入了勒索后的应急处置环节，模拟演练，就是写报告。

A8：

HVV常态化，在精力、财力有限的情况下，需要寻找一些回报率高的安全建设方法，从攻击者视角做一些安全建设。

A9：

常态化需要持续运营，比如WAF突然失效了，HIDS什么规则突然不报警了，得持续监控。

Q：某些应用系统经常爆发0Day漏洞，因其已经购买和使用较久，目前版本过低，厂商已经不维护了，但如果要升级，需要较高的费用，企业没有预算。常态化攻防下，无法直接拔网线了，大家有什么防护的方法建议？

A10：

最好能找钱找资源更新，如果实在找不到，就想办法让业务下线，改变实现方式，不然永无宁日。

A11：

得看什么系统，不让把网线，不代表这个业务不能黑白名单或者隔离不对红队开放。

A12：

这建议还是收进内网了，如果是tC业务建议还是重构吧。

A13：

这个是否可以先考虑收敛下网络访问度，收敛下攻击面，如果系统安全性低，还依然全互联网开放肯定违背了安全最佳实践的，或者找替代方案逐步切换。

A14：

收敛暴露面同时常态化进行安全测试，对供应链系统进行严格ACL策略访问。其实改变业务方式对于安全来说，特别是互联网企业是不现实的。

A15：

这种系统肯定不是业务系统，最多是内部管理， 不行就套娃，服务隔离后，SASE或者零信任套外边。

A16：

收敛到可接受的程度，至于收敛的手段或程度，千人千面。

A17：

网络隔离，使用通过Jumpserver。

A18：

考虑一下迁移到云平台，利用云平台的安全服务和资源。

A19：

云平台现在安全性问题也大，说实话，对于一些云平台最好打，比域好打多了。

A20：

根据业务需求，各模块最小化，能关尽关。

A21：

一般装主机入侵防御+态势感知类产品，然后严格限制网络访问权限，锁定某些主机文件权限，接口类添加认证代理，加强告警值守，最关键是定一个系统负责人，让他自己同时做好监控。

A22：

如果从技术角度思考这个问题，无非就是加WAF等一些安全设备，我感觉这更像是一个安全管理的问题，明知有漏洞，还不修复，最后出事儿背锅的安全部门得占一大半。

A23：

这是种常见的问题。之前也遇到过。

1. 首先联系厂商协调资源，说明情况，摆出法律要求，厂商是有协助用户整改漏洞的义务的，因此造成的影响乙方应承担责任（破皮打滚就赖他）通常在应用系统采购时合同里面会约束这些条款。通过给乙方施压，协助漏洞整改维护。

2. 遇到类似0Day漏洞，通常开源的安全防护系统也能起到一部分缓解作用。

通常出现这种情况的时候，会涉及到负责运维应用系统的业务部门和应用系统厂商的多方沟通，安全部必要时需要倒逼业务部门和乙方进行风险转述，甚至还需要出面解释风险。能够解决业务漏洞是最好的结果。还有就是暴漏0Day出现不良影响后（挖矿，勒索事件），解决这种问题反而更加好解决。因为师出有名，安全部可以理直气壮的要求漏洞整改。不管是不是在合同期或者维保期内，乙方都是有责任去整改漏洞的。

Q：常态化后，攻击者有更多的时间收集信息和隐蔽潜伏，要如何更好地发现和整改？

A24：

常态化都疲掉了，随便搞、和平常一样就行，HVV后有攻击途径报告，跟着改就行了，有些被攻击队挂马的链接尤其要注意、否则其他都整改了，下次还直接进来。

A25：

7*24值守，针对各种攻击有相应的设备和工具监控，日严格最小化开放，与业务、安全厂商及时分享互联网业务情报，功夫在平时。

A26：

平时定期按照标准的资产梳理、暴露面收敛、漏扫、渗透、封堵、账号排查、互联网信息排查、意识培训这一套标准流程搞就差不多了，只是HVV期间加强人员值守提高下处置速度。

A27：

我最担心的是其实好多业务系统的数据已经被黑客拿走了，最简单的SQL注入。只要是放在互联网上，数据其实已经被拿走了。

A28：

数据泄露这块，三方开发导致的很多，还不好根治，上海那次就是这种，也实际遇到过。

A29：

这个问题其实相当于安全也常态化了，不再是那种请人来驻场解决问题，逼迫某些企业有自己的安全成员来负责这些事情，或者是直接上MSS托管。

A30：

做长周期的全流量和日志审计留存，调查分析挖掘，感觉要往APT对抗上走了，甲方往往缺乏分析能力，乙方分析则倾向于单点事件 。

Q：以往战时方案提及的如IP封禁方法、特权账号限制等，在常态化攻防下，有什么新的应对策略？

A31：

公司互联网暴露面收敛，加大攻击对信息收集难度，还有开源软件安全评估。

A32：

通过SOAR自动化分析和封禁。

A33：

1. 重要业务系统使用多因素身份认证或者动态密码；

2. 使用自动化的工具编排处置场景，当然也要自动化封禁；

3. 利用实时威胁情报平台，获取最新的攻击信息和漏洞信息，及时调整安全策略；

4. 通过各种途径进行安全宣传，提高员工的安全防范意识。

A34：

今年可以AI助力，大模型用起来，常用的策略手段落实到位就挺好。

附：群成员对HVV的一些看法

A1：

HVV的初心是检验安全工作的效果，即检查安全检测（监测）、防御、应急响应等能力，改进安全体系，最终提高安全水位线。常态化也好的，我也经常和团队的人用个打比方的形式来说，HVV就好比读书时的考试，好学生平时就好好学习，管它什么时候考试，那些平时没那么用心学习的同学可能会做类似考前冲刺等努力的事（这类相对来说是高强度的，容易让人疲惫）。所以，我们要做个好学生，平时就好好学习，管它什么时候HVV。

A2：

如果以考试做比喻，HVV是邀请全国最能出卷子的人出一套奥数卷子给你做。但是你平时就是做普通的卷子，奥数肯定不行，所以要找专门做奥数的来复习和强化奥数能力。

A3：

HVV材料里对于攻击成功扣分的枚举还是比较清晰的，如果是0Day被干出去了，没什么可遗憾的。如果是其他原因，那是可以先举一反三看看怎么解决，再深度思考如何改进安全体系，从根本上让问题不出现或即使出现，你也能感知到。

A4：

HVV跟考试还是很大不同的，考试只有0跟1，对就是对，错就是错，有标准答案。演戏就有很多灰色地带了，一个没价值的漏洞，内部已知的，结果演员一发现就说是高危甚至严重，还骑脸输出说安全工作没做好。

A5：

真的通报来了，肯定是要改的，但是你可以给出说明函的，按照DREAD等模型，内部的风险定级是怎么样的，你老板认可你做的行也OK的。安全不花钱买总得花钱招些人吧，公司既然设立了安全部，组织架构上认可这个部门的存在，团队Leader平时也需要做好些基本工作，适当做些向上管理汇报，让老板逐步认可工作产出，认可价值。

本周话题总结

随着HVV将近，本期主要讨论了常态化HVV的一些特性，大家认为主要是AI带来的新风险、老旧系统0Day漏洞的防护策略，以及安全管理的重要性。企业需要采用多种措施来确保网络安全，包括限制访问、加强设备部署、跨部门协作等。

针对常态化后的风险发现及整改，认为关键在于持续的监控、及时的信息分享、以及定期的安全评估与培训，企业需要实施更加严格的网络暴露面管理、开源软件安全评估以及使用自动化工具来加强监控和处置。此外，利用时下流行的AI大模型也能有效提高防御能力。

近期群内答疑解惑

Q：公司自建加解密服务给业务调用， 怎么规避业务私自留存明文和密文的关联关系？

A1：

OTP，或者私钥绑定，定期更换，加密系统对目录和磁盘定期扫描，强制再加密。如果是自开发的加解密系统，可以在客户端加个检查记录功能，记录曾经解密了啥文件，然后比如24小时以后自动再加密。

A2：

业务调用加密的时候，单拎一张表同时记录明文和加密服务返回的密文，然后想用的时候直接查表，不调用解密。

A3：

直接用DH不好吗？轮换秘钥。

A4：

轮换后也需要给他们密文啊， 他们有关联关系。

A5：

加解密你当一个基础服务就好了，给密文不影响，不是给私钥就行。

A6：

他给我明文，我返回密文，然后他私自记录明文和密文的关联关系，不需要调解密就能关联出明文吧，私钥给不给已经无所谓了吧。

A7：

那你就把加解密过程都在基础服务执行就好了。

A8：

但是最终的表现还是：业务给明文，你返回密文，中间加几层应该无所谓。可能是我想法不太多，但是业务有心留存明文和密文的关联关系，怎么治理呢？

A9：

你的思路反了，应该是默认加密，业务可以要求解密。

A10：

在哪加密呢？

A11：

你们应该是应用上面有身份秘钥，去调KMS的加解密秘钥来加解密。你现在的问题是身份的认证秘钥怕被开发滥用是吧？

A12：

场景对，问题是他们正常业务调用，审计不出来， 但是从其他渠道发现他们留了一个库表写关联关系。或者各位CSO，敏感数据加密怎么实施的，有天然规避这个场景的方案不？

A13：

你一个key绑定一个IP，正常也不好滥用吧，只允许对应的机器调用，然后开发也没有生产权限。

A14：

你的话题比较笼统，应该细分一下场景，设计密钥的使用方式、匹配方式和时效性啥的。

A15：

1. 自建的KMS， 按照数据 字段 + 行为（加密、解密、脱敏等） 组合分发授权Key；
2. 审计调用的源IP是否一致；调用的频次和方式是否与业务一致；特殊场景关联对比上下游服务的调用记录；
3. 遇到的问题是，有个业务正常申请授权，业务调用记录也是按需使用Key， 但是在业务正常调用时，本地留存了一份关联关系。

A16：

噢，就是按理是临时查询的数据自己偷偷地存下来了。

A17：

对，怎么能发现或者解决呢？

A18：

你在库里就能发现呀。

A19：

针对敏感数据加密，规避方案就是不采集敏感数据，这个最天然了，在采集阶段就匿名化，脱敏是最好的，要不然你都得全流程追溯，非常麻烦，风险点也多。

A20：

还是得就着场景说吧，有业务需求的情况下不可能一刀切不让人家用，数据不让用那还有啥用呢。

A21：

能用着敏感数据的业务不多，让他们自行按照个人信息保护法和数据安全保护法进行合规审计，你已经尽了告知义务，希望他们尽快通过PIA审计。从根本上讲，安全从业人员也是这些敏感数据的不相关人员，我们本身也不能碰这些数据，顶多做一下内审罢了。到时候抓人的时候，就把业务抓走就好了，我们还得继续给阿Sir们当卧底呢。

A22：

能不采集当然最好，但很多情况下业务其实是想要的，再退一步你可以规范强制使用加密组件，还不行你就扫库，扫到明文要求整改。

Q：请教一下关于https SSL证书方面，每年SSL需要更换购买新证书，几十个业务系统需要停，应用部署新证书花费大量时间。有没有什么好办法或者设备，可以不用在每个应用上部署SSL证书实现https SSL证书的目的？

A1：

Nginx好像有动态证书轮换的功能，F5建议用LTM，别用SSLO。

A2：

有全链路加密，过程中替换个别证书，停个别应用也可以做到不影响全局啊。仅前端加密，过程中无替换证书这一场景了。

A3：

我也想问，每年都要更换证书，太麻烦了，能不能直接在反代上启用ssl证书，然后内网使用Http，到时直接更换反代上的SSL证书就可以了？

A4：

肯定可以啊，除非极个别业务有监管要求必须全链路加密。

A5：

更换SSL证书的同时，相关安全设备也要同步配置，真的很麻烦，经常会漏掉。导致安全设备策略不起作用，相应攻击也监测不到。

A6：

SSL证书直接配在WAF吧，后端明文也能接受，否则一个泛域名证书更换，人力和时间成本太高。

原文始发于微信公众号（FreeBuf）：常态化HVV有哪些特性，该如何应对 | FB甲方群话题讨论