漏洞渗透测试工作中遇到的一些问题总结

例MS17-010补丁刚发布的时候,其漏洞的严重程度微软说得很清楚,但立即安排全公司最快速度使用补丁的团队并不多,他们在Wannacry肆虐后,却喜欢宣传自己的紧急加班方式。由于紧急加班可以在一个周末完成,4个多月前,为什么要去呢?另外,主机agent在部署时,很容易造成资源占用过多,Bug导致宿主机崩溃,所以很多安全工程师写完agent后,在公司没有100%的推广覆盖。由于无法安装多少台,一次事故就会让业务排斥抗拒部署,导致公司实际上根本没有主机入侵检测的能力。但是,既然知道这件事是必然的结果,熔断降级自杀设计有没有,能不能让公司95%以上的机器具备相应的能力先?长尾问题慢慢迭代收拾?


例如,白盒审计工具扫出了大量的误报,以致无法操作,那有没有想过只让误报低的规则运行起来,逐个增加和优化规则,在低误报的前提下,提高白盒的能力?所有这些,没有经验的同学一上来往往都会畏难,你说这件事做得成功,只是他当时做得不对,他还是会感到委屈。急急忙忙地妥协地做些费力可能还没有效果的事情,至少不能正常经营下去,临时处理表明自己是顺从和尽责的。所以,我认为,评价安全工作好坏的第一条,其实对当事人的认知能力要求最高,至少要知道这件事,是否能做好,要有客观的认识。而且这种认知能力除了自己探索学习之外,实际上还有捷径可走。即行业对标。同样的事情,把国际、国内、同规模公司的现状摸一摸,多多少少会有合理的判断,当然,由于安全行业成熟度一般,所以有很多实际上可以做好的事情,国内同行没有做好,造成误判,也很常见。这个话题就按下来了。



二、投入的合理性。在有合理认知的前提下,首先要考虑的是自己领域的风险全景图和合理的应对节奏。其实用对标的方法输出并不难。很难。很多人会抱怨自己目前的资源现在的资源,不能做这么多事情。由于资源不足,所以即使知道很多风险没有解决,暂时也不去动它,这件事不能怪自己,要怪领导不重视,不投入。这个观点其实也有问题。对企业高层来说,绝大多数时候,认可企业资源并不足以支持你舒适地做事。但这并不意味着,一件非做不可但事,企业也坚持不给资源。没有资源的道理只有一个——你没有有效地说清楚这件事,而这,并非经理的错。比方说,老板手里有一百万,现在沙漠里,口渴了,旁边有人拿着农夫山泉卖100块,你觉得很贵不划算,默认老板不会掏钱,所以没有告诉老板有水卖。但是你怎么知道老板不愿意掏这100块呢?诚然,也确实有很多从业人员会夸大其词,自己YY安全风险很大,能带来的后果,比这家公司的市值、营业额还要大很多,然后老板不予置评,不支持,感到委屈。事实上,大多是没有换位思考,假设自己是老板的partner,在众多的经营风险中,公司有限的资源,到底该分配多少来处理这些事情。直截了当地说,如果你能处理的风险盘很大,而公司还没有达到相应的阶段,我认为最好的策略可能是跳槽去一家更加重视安全的公司,而不是在目前的公司中欺骗老板在安全领域投入过多的资源——否则,公司的主要业务能否发展起来还不知道,资源可能会先消耗掉。


假定,资源问题放在一边,已经确定只有有限的资源,面对风险大盘,如何看菜下饭合理分配,其实也很考验安全负责人的认知。实用,但不出彩的地方要投入,实用,但对于团队前瞻性或知识结构储备的地方,同样值得投入。特别是,当安全负责人自身视野有限时,花费大量资源,但以非常低效的方式解决单一问题,以致其他风险投入不足,却误以为是高层不支持不投入的现象,也很常见。比如大部分公司都会有一个问题,就是权限控制,大多不符合最小化的最佳安全实践。因为权限分散在太多系统中,运维权限、DB权限、应用系统权限(知识库、代码仓库、报表平台、人力资源系统…),公司规模越大,这些系统越多。


而且这些权限问题往往很容易暴露给高层看,总会发生事故,所以安全团队必须迎难而上。一些同学会非常努力地承担权限管理的责任,试图帮助公司的每个系统,设计一份权限管理清单,谁能访问,谁不能访问。由于兹事体大,因此也会投入大量的人力,长期地做这个项目,做到最后,各种采访,各种调查,各种数据分析,判断谁应该访问哪个权限。(这还不算开发全球IAM权限管理系统的工作量)。企业规模越大,完成这些工作的时间就越长,可能无法完成,一段时间后,内部的红蓝对抗仍然可以很容易地暴露问题,权限仍然没有收敛到预期的目标。但是,原本捉襟见肘的安全团队,确实在这个项目上投入了大量的精力,以致于还有许多其他同样重要的风险,无法进行治理。


分享: