安全风险评估的3种错误方式-阿里云开发者社区

开发者社区> 安全> 正文

安全风险评估的3种错误方式

简介:

即使计算机安全防御专家也难以区分真正的威胁和假警报。这里列出应该避免的3种关键却又普遍的错误。

安全风险评估的3种错误方式

计算机安全人员在防御这件事上是出了名的不成功。原因很多,不仅仅是因为他们要承担所有的责任却又没有足够的权限。

用户总是义无反顾地无视他们收到的好建议,甚至努力绕过安全控制。但是,在当今这混乱的计算机安全状况下,责备他人的行为总是再容易不过。

考察一下修复程序,修补崩溃系统的第一步就是要承担你自己的责任。在我看来,计算机安全最大的问题之一就是防御者不能正确地评估风险。他们将太多较低的风险列为了高风险,而太多的高风险又被认为是不需要关注的。

有3个原因可以解释为什么计算机安全防御者总是做出错误的判定。总的来说,这几点解释了为什么大多数公司把大部分IT预算花在了根本不能使他们免于受到侵害的项目上。

1. 混淆了媒体炒作和真正的风险

当企业被媒体对最新漏洞铺天盖地的报道所淹没,谁能责备我们对之投以关注?这就是事实真相。今天的威胁总是伴随着媒体热炒,甚至还有它们自己的标识。要无视它们真心太难——不过大多数时候我们真的应该无视之。

举个绝佳的例子:任何网络攻击都需要黑客预先进行多种多样、单独的、成功的攻击铺垫。复杂性不只是防御者的敌人。通常,媒体报道中根本不会提到这些必要的先决条件——或者只是一带而过,就好像这些复杂的攻击准备非常容易实现。

比如说,你可能听说过这样的一次网络攻击:攻击者必须首先用中间人攻击进行掩护才能够开始实施下一波攻击。几年之前,很多黑客工具让中间人攻击相当容易达成。只需要连上网络,点击一个按钮,嗖的一下你就成了网络之主——通常是用ARP投毒实现的。

但是,在今天,公司网络系统通常会采用网络设备抵御ARP投毒攻击,中间人攻击已经很难在这些系统中成功实施了。即使攻击者侥幸成功,他们也常常会造成太多计划外的破坏而导致公司网络维护团队最终重启网络以解决问题,显然,中间人重路由挺不过网络重启这种终极大招。

2. 没聚焦到问题根源

攻击发生后,防御者的重点常常放在了攻击者侵入之后做了什么,而不是他们最开始是怎么突破防御的。确实,我们需要评估损失并确保攻击者被驱离。但我们也应该至少将同样的精力,投放在判定黑客是怎样获取到访问权的,并保证此类漏洞不会被再次利用。

哈希传递攻击是个不错的例子。这种攻击中,攻击者必须首先获取有根用户、本地管理员用户或者域管理员用户安全上下文的系统访问权。一旦他们获取到此类提升的安全权限,他们几乎能在系统中畅通无阻为所欲为。世界尽在他们掌握。我们也许可以完全阻止哈希传递攻击,但我们丝毫阻止不了攻击者。他们能做任何他们想做的事。防得了一次防不住第二次,他们会改变方式卷土重来。

在坏人拿到你的管理员帐户后担心哈希传递攻击就像是担心偷你车的小偷会不会善待你的刹车似的。

3. 没向管理层汇报真正的风险

经常听到人们抱怨说高级管理层没有真正支持IT安全团队或者给他们履职尽责所需的工具和资源。大多数情况下,这不过是逃避责任的借口。IT安全团队没有与管理层共享正确的信息倒是更为典型的症状。

我还从未见过哪个高管在明确知悉各种风险及各风险优先级的情况下不给安全部门大开绿灯的。然而不幸的是,大多数IT安全部门总是将一堆“No.1”风险摆在管理层面前,向管理层索要一堆各不相同的“高优先级”项目的资金支持。然后,IT安全团队坐一边百思不得其解,“为什么我们真正的No.1威胁没能有效解决呢?”

这么说吧,如果没打补丁的软件是你的首要问题(多数公司里,最高级别的威胁与少量没打补丁的程序有关),如果你毫不含糊地向你的高级管理层解释清楚了这一点,管理层将会给你专注于打补丁的权限和工具的。

计算机安全防御从来都不是件容易的事。我们面对的是一大堆棘手的问题和风险。但如果我们不能正确评估威胁,不能向高级管理层传达必要的有用的信息,安全防御就是句空话。


作者:nana

来源:51CTO


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章