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什么规则突然不报警了,得持续监控。
A10:
最好能找钱找资源更新,如果实在找不到,就想办法让业务下线,改变实现方式,不然永无宁日。
A11:
得看什么系统,不让把网线,不代表这个业务不能黑白名单或者隔离不对红队开放。
A12:
这建议还是收进内网了,如果是tC业务建议还是重构吧。
A13:
这个是否可以先考虑收敛下网络访问度,收敛下攻击面,如果系统安全性低,还依然全互联网开放肯定违背了安全最佳实践的,或者找替代方案逐步切换。
A14:
收敛暴露面同时常态化进行安全测试,对供应链系统进行严格ACL策略访问。其实改变业务方式对于安全来说,特别是互联网企业是不现实的。
A15:
这种系统肯定不是业务系统,最多是内部管理, 不行就套娃,服务隔离后,SASE或者零信任套外边。
A16:
收敛到可接受的程度,至于收敛的手段或程度,千人千面。
A17:
网络隔离,使用通过Jumpserver。
A18:
考虑一下迁移到云平台,利用云平台的安全服务和资源。
A19:
云平台现在安全性问题也大,说实话,对于一些云平台最好打,比域好打多了。
A20:
根据业务需求,各模块最小化,能关尽关。
A21:
一般装主机入侵防御+态势感知类产品,然后严格限制网络访问权限,锁定某些主机文件权限,接口类添加认证代理,加强告警值守,最关键是定一个系统负责人,让他自己同时做好监控。
A22:
如果从技术角度思考这个问题,无非就是加WAF等一些安全设备,我感觉这更像是一个安全管理的问题,明知有漏洞,还不修复,最后出事儿背锅的安全部门得占一大半。
A23:
这是种常见的问题。之前也遇到过。
1. 首先联系厂商协调资源,说明情况,摆出法律要求,厂商是有协助用户整改漏洞的义务的,因此造成的影响乙方应承担责任(破皮打滚就赖他)通常在应用系统采购时合同里面会约束这些条款。通过给乙方施压,协助漏洞整改维护。
2. 遇到类似0Day漏洞,通常开源的安全防护系统也能起到一部分缓解作用。
通常出现这种情况的时候,会涉及到负责运维应用系统的业务部门和应用系统厂商的多方沟通,安全部必要时需要倒逼业务部门和乙方进行风险转述,甚至还需要出面解释风险。能够解决业务漏洞是最好的结果。还有就是暴漏0Day出现不良影响后(挖矿,勒索事件),解决这种问题反而更加好解决。因为师出有名,安全部可以理直气壮的要求漏洞整改。不管是不是在合同期或者维保期内,乙方都是有责任去整改漏洞的。
A24:
常态化都疲掉了,随便搞、和平常一样就行,HVV后有攻击途径报告,跟着改就行了,有些被攻击队挂马的链接尤其要注意、否则其他都整改了,下次还直接进来。
A25:
7*24值守,针对各种攻击有相应的设备和工具监控,日严格最小化开放,与业务、安全厂商及时分享互联网业务情报,功夫在平时。
A26:
平时定期按照标准的资产梳理、暴露面收敛、漏扫、渗透、封堵、账号排查、互联网信息排查、意识培训这一套标准流程搞就差不多了,只是HVV期间加强人员值守提高下处置速度。
A27:
我最担心的是其实好多业务系统的数据已经被黑客拿走了,最简单的SQL注入。只要是放在互联网上,数据其实已经被拿走了。
A28:
数据泄露这块,三方开发导致的很多,还不好根治,上海那次就是这种,也实际遇到过。
A29:
这个问题其实相当于安全也常态化了,不再是那种请人来驻场解决问题,逼迫某些企业有自己的安全成员来负责这些事情,或者是直接上MSS托管。
A30:
做长周期的全流量和日志审计留存,调查分析挖掘,感觉要往APT对抗上走了,甲方往往缺乏分析能力,乙方分析则倾向于单点事件 。
A31:
公司互联网暴露面收敛,加大攻击对信息收集难度,还有开源软件安全评估。
A32:
通过SOAR自动化分析和封禁。
A33:
1. 重要业务系统使用多因素身份认证或者动态密码;
2. 使用自动化的工具编排处置场景,当然也要自动化封禁;
3. 利用实时威胁情报平台,获取最新的攻击信息和漏洞信息,及时调整安全策略;
4. 通过各种途径进行安全宣传,提高员工的安全防范意识。
A34:
今年可以AI助力,大模型用起来,常用的策略手段落实到位就挺好。
A1:
HVV的初心是检验安全工作的效果,即检查安全检测(监测)、防御、应急响应等能力,改进安全体系,最终提高安全水位线。常态化也好的,我也经常和团队的人用个打比方的形式来说,HVV就好比读书时的考试,好学生平时就好好学习,管它什么时候考试,那些平时没那么用心学习的同学可能会做类似考前冲刺等努力的事(这类相对来说是高强度的,容易让人疲惫)。所以,我们要做个好学生,平时就好好学习,管它什么时候HVV。
A2:
如果以考试做比喻,HVV是邀请全国最能出卷子的人出一套奥数卷子给你做。但是你平时就是做普通的卷子,奥数肯定不行,所以要找专门做奥数的来复习和强化奥数能力。
A3:
HVV材料里对于攻击成功扣分的枚举还是比较清晰的,如果是0Day被干出去了,没什么可遗憾的。如果是其他原因,那是可以先举一反三看看怎么解决,在深度思考如何改进安全体系,从根本上让问题不出现或即使出现,你也能感知到。
A4:
HVV跟考试还是很大不同的,考试只有0跟1,对就是对,错就是错,有标准答案。演戏就有很多灰色地带了,一个没价值的漏洞,内部已知的,结果演员一发现就说是高危甚至严重,还骑脸输出说安全工作没做好。
A5:
真的通报来了,肯定是要改的,但是你可以给出说明函的,按照DREAD等模型,内部的风险定级是怎么样的,你老板认可你做的行也OK的。安全不花钱买总得花钱招些人吧,公司既然设立了安全部,组织架构上认可这个部门的存在,团队Leader平时也需要做好些基本工作,适当做些向上管理汇报,让老板逐步认可工作产出,认可价值。
随着HVV将近,本期主要讨论了常态化HVV的一些特性,大家认为主要是AI带来的新风险、老旧系统0Day漏洞的防护策略,以及安全管理的重要性。企业需要采用多种措施来确保网络安全,包括限制访问、加强设备部署、跨部门协作等。
针对常态化后的风险发现及整改,认为关键在于持续的监控、及时的信息分享、以及定期的安全评估与培训,企业需要实施更加严格的网络暴露面管理、开源软件安全评估以及使用自动化工具来加强监控和处置。此外,利用时下流行的AI大模型也能有效提高防御能力。
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:
能不采集当然最好,但很多情况下业务其实是想要的,再退一步你可以规范强制使用加密组件,还不行你就扫库,扫到明文要求整改。
A1:
Nginx好像有动态证书轮换的功能,F5建议用LTM,别用SSLO。
A2:
有全链路加密,过程中替换个别证书,停个别应用也可以做到不影响全局啊。仅前端加密,过程中无替换证书这一场景了。
A3:
我也想问,每年都要更换证书,太麻烦了,能不能直接在反代上启用ssl证书,然后内网使用Http,到时直接更换反代上的SSL证书就可以了?
A4:
肯定可以啊,除非极个别业务有监管要求必须全链路加密。
A5:
更换SSL证书的同时,相关安全设备也要同步配置,真的很麻烦,经常会漏掉。导致安全设备策略不起作用,相应攻击也监测不到。
A6:
SSL证书直接配在WAF吧,后端明文也能接受,否则一个泛域名证书更换,人力和时间成本太高。
上期话题回顾:
HVV期间的VPN安全策略;如何管理远程桌面软件活动回顾:
19岁成为「传奇黑客」,27岁当上电信首席专家,这位95后开了挂?
巴菲特股票暴跌99%?纽交所IT系统出现重大技术故障
GDPR罚单开到爽,这家公司贡献了大头
FreeBuf甲方社群每周开展不同的话题讨论,快来扫码加入我们吧!
【申请流程:扫码申请-后台审核(2-5个工作日)-邮件通知-加入社群】
注:目前1群、2群已满,如有疑问,也可添加Kiki群助手微信:freebuf1024,备注:甲方会员
“FreeBuf甲方群”帮会已建立,该帮会以三大甲方社群为基础,连接1300+甲方,持续不断输出、汇总各行业知识干货,打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口,让我们一同加入,共同建设帮会内容体系,丰富学习交流地。