十个很少有人谈到的网络安全风险因素

安全 应用安全
我们都在与庞大的估算做斗争,但是还有很多其他因素影响着风险管理。这里有 10 个很少被公开讨论的问题。

这些风险因素可能不会出现在官方的风险评估报告中,但是每个安全专家都应该考虑这些因素。

[[280774]]

传统的风险管理通常包括对潜在的威胁和风险进行分类,评估其发生的可能性,以及估算如果不能减轻它们可能造成的损失。潜在的缓解和控制成本是根据潜在损失来衡量的。如果减轻措施比风险和威胁发生的成本更低、实施效果更好,那么就会采取相应措施。

大家都曾为计算一个事件的可能性及其潜在损失而烦恼过。这一过程一直更像是一种最佳猜测,而不是保险精算表。谁能估计在某一年一个复杂的勒索软件、DDoS 或内部攻击在他们的组织机构中发生的概率或者能够准确预测哪些资产会受到影响?有人能证明某年的可能性是20%还是 60% 吗?

我们都在与庞大的估算做斗争,但是还有很多其他因素影响着风险管理。这里有 10 个很少被公开讨论的问题。

1. 应对“可能发生”的风险

每一次风险评估都是在应对可能发生的事情和什么都不做之间进行斗争,尤其是在以前从未发生过的情况下。很多人认为什么都不做更省钱,那些为某事而奋斗的人可能会被认为是在浪费钱。“为什么要浪费钱?那永远不过发生!”

很少有人会因为保持现状和墨守成规而惹上麻烦。尤其是在涉及大笔资金的情况下,积极采取行动,要比坐等损失出现并解决问题要困难得多。

以 911 和航空旅途安全举例。并不是说航空安全专家们在 2001 年 9 月 11 日之前就不知道劫机者可以通过一把美工刀控制驾驶舱,或将爆炸物偷运上飞机。这些风险早在几十年前就已为人所知。想象一下,如果在 911 事件发生之前,乘客就被要求扔掉水瓶并接受全身扫描,会引起公众多么强烈的抗议。这可能会激怒公众,航空公司也会主动去掉这些安全措施。

911 之后,我们很乐意脱掉鞋子,扔掉水瓶,接受全身扫描。获得资金来应对可能的风险要比在损失发生后获得资金困难得多。每当风险评估人员就从未发生过的问题发出警告时,都非常需要勇气。他们是无名英雄。

2. 政治风险

主动承担风险会引发相关的未知风险之一:政治风险。每当积极主动的英雄们争取应对从未发生的事情时,他们都会失去一点政治资本。他们只有在他们积极主动去应对的事情发生的时候才能获得胜利。如果他们能成功说服公司实施控制和缓解措施,那么糟糕的事情就永远不会发生,好吧,它永远不会发生。

这是一个悖论。当他们胜利的时候没有人知道,因为他们成功争取到了控制。所以,每当他们担心的事情从未发生时,他们就会被视为 “狼来了”。他们失去了政治资本。

任何经历过这些风险管理斗争的人都可以告诉你,他们不想承担太多的挑战。每一次斗争都会给他们的声誉带来一点损害(或很多)。所以,这些战士们会计划他们想要打哪些仗。随着时间的推移,经验丰富的战士会减少战斗次数。他们不得不这么做。适者生存。他们中的很多人只会等待某一天,当一件真正糟糕的事情发生时,他们没能为组织机构止损而斗争,而成为了替罪羊。

3. “我们说已经做完了,但并不一定”的风险

我们所说的很多控制和缓解措施并没有真正完成,至少没有达到 100%。很多人在这个过程中明白事情并没有真正完成。最常见的例子是打补丁和备份。我知道的大多数公司都说他们打了 99% 到 100% 的补丁。在本文作者 30 多年的职业生涯中,检查了数百万台设备的打补丁状况,但从来没有发现一个设备是安装了所有补丁的。然而审计过的每家公司都会说,他们已经安装了所有的补丁,或者接近完成了。

备份也是如此。当前勒索软件的泛滥暴露了大多数组织机构并没有做好备份。尽管大多数组织机构和他们的审计人员多年来都在检查是否已经完成了关键备份,并定期进行测试,但只要一次大型勒索软件攻击就能显示出真相是多么的不同。

风险管理领域的每个人都知道这一点。在没有时间和资源的情况下,负责备份的人如何能够测试所有内容呢?要测试备份和恢复是否可以工作,你必须对很多不同的系统进行恢复测试,并将其同时放到必须工作的单独环境中(即使所有资源都指向原始环境)。这需要投入大量的人力、时间和其他资源,而大多数组织机构都不会给负责人这些承诺。

4. 制度化的风险:“一直都是这么做的”

很难反驳 “我们一直都是这么做的”,尤其是在几十年都没有发生针对弱点的攻击的情况下。例如,我经常遇到允许密码为 6 个字符且从不修改的组织机构。有时是因为PC网络的密码必须与连接到公司所依赖的一些古老的 “大家伙” 系统的密码相同。每个人可能都知道,6 个字符且不变的密码不是一个好主意,但这从来不会造成任何问题。

如果你认为所有东西都需要升级,以支持更长的、更复杂的密码(可能要花费数百万美元),那么制度化的“智慧”是不利于你的,而大多数人在组织机构中的时间比你长得多。

5. 业务中断的风险

你所实施的每个控制和缓解措施都可能导致运营问题。而且甚至可能会中断运营。你更有可能因为运营意外中断而被解雇,而不是提前预防了一些理论上的风险。对于你推动的每一项控制和缓解措施,你都要考虑是否会导致潜在的运营中断。

控制越彻底,就越有可能减少其所抵御的威胁带来的风险,但你会更怀疑是否可以在不中断运营的情况下做到这一点。如果在不造成运营中断的情况下降低风险是容易的一件事情,那么每个人都会这么做。

6. 员工不满的风险

没有哪个风险经理想让员工生气。如果你想要这种情况发生,就限制他们可以访问的 Internet 地址和他们在计算机上的操作。70% 到 90% 的恶意数据泄露(通过网络钓鱼和社会工程)都是由终端用户造成的。你不能相信终端用户能靠直觉保护组织机构。

然而,仅仅限制终端用户操作,比如只允许预先批准的程序运行,或者限制他们对互联网的访问和操作,就会遭到大多数员工的反对。劳动力市场供不应求。每个公司都在努力争取优秀的员工,他们不想被告知他们不能在“他们的”电脑上做任何他们想做的事情。你锁定的太多,他们可能会去别的地方工作。

7. 客户不满意的风险

没有人愿意实施一项让客户失望的政策或程序。沮丧的顾客会变成其他公司的快乐顾客。例如,与阻止欺诈相比,信用卡公司更关心的是意外拒绝合法客户的合法交易。他们关心欺诈,但他们认为这是一种长期行为。那些使信用卡交易更准确的承包商和公司向信用卡公司出售他们的服务,说明他们如何减少拒绝合法交易的情况。一年内有两次交易被意外拒绝的顾客将会使用其他银行的信用卡。

这也是为什么在美国你不需要使用带有 PIN 码的芯片卡。世界其他地方需要芯片和 PIN 码,这是目前为止更安全的选择。美国是怎么做到的呢?因为 PIN 码和芯片卡进入美国的时间相对较晚,商户和客户刚刚习惯刷卡。要求人们插入卡片以正确读取芯片将会使一小部分交易失败,并使一些客户不满。

8. 前沿风险

站在最前面的人容易被当成炮灰。没有人愿意站在矛尖上。早期采用者很少会因为行动早而得到奖励。他们往往会成为经验教训,有益于后人采用改进的策略。

两年前,美国国家标准与技术研究院 (US National Standards and Technology, NIST) 表示,其长期以来要求使用长而复杂密码并定期更换的密码策略,导致的黑客攻击要比其阻止的多。其新的《数字身份指南》,NIST 特别出版物 800-63-3 (NIST Special Publication 800-63-3),表示密码可以是简短的,不复杂的,并且除非你知道密码已经被泄露,那你永远不会被强制修改密码。与先前被认为是教条的建议相比,这是一个 180 度的大转变。

从那以后,没有任何合规指南或监管法律得到更新,表明采纳新建议是可取的或合法的,也没有见到或听说任何公司采用了新策略。这可能是一件好事,因为如果你改变了你的策略,并因此而遭到攻击,即使 NIST 说这是正确的做法,人们也会指责你,问你为什么这样做。等待大群体转向新的密码策略要安全得多,看看他们是对的还是错的。

9. 滞后风险

你总是在与已经发生在其他人(或你的组织机构)身上的风险作斗争。你等着看黑客有什么花招,然后建立缓解和控制措施,以对抗这些新的风险。必须先等黑客出招,就造成了从发现新的恶意行为到评估新技术、考虑新控制并实施中间的时间差。在观望中,你总是会落后。

10. “不可能事事正确”的风险

去年公布了超过 16555 个新漏洞。已知有超过 1 亿个独特的恶意软件程序。从民族国家黑客到金融窃贼,再到脚本小子,他们都试图入侵你的组织机构。你要担心的事情太多了。除非有人给你无限的金钱、时间和资源,否则你无法抵御这一切。你所能做的就是猜测(见第一条)哪些是最重要的风险,并试图阻止它们。

这些都不是风险评估的新组成部分。它们一直都在,它们是你们在评估风险和考虑控制时会想到的。所有这些都表明风险评估和风险管理比表面看上去要困难得多,尤其是和书本理论相比。当你考虑到普通计算机安全人员需要担心和考虑的所有事情时,你会惊奇地发现,我们在大多数时候能够处理好。

【本文是51CTO专栏作者“李少鹏”的原创文章,转载请通过安全牛(微信公众号id:gooann-sectv)获取授权】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2018-10-08 15:14:31

2021-12-03 17:13:04

CIO运营IT

2023-09-06 07:22:48

控制台UI工具

2013-04-24 09:22:54

2023-04-24 12:03:55

2023-10-08 11:03:59

2023-07-24 12:28:26

2022-09-21 00:09:02

Linux软件恶意软件

2024-08-06 09:51:21

SpringHTTPJSON

2018-06-04 22:27:47

2023-09-06 12:01:07

2021-10-05 09:02:14

网络安全管理

2021-04-23 22:37:45

网络安全软件系统

2024-03-13 12:39:46

2012-05-14 10:49:53

2023-07-29 00:13:50

2024-06-18 09:59:46

2011-08-11 11:13:24

2022-12-13 16:44:10

JavaScrip工具开发

2021-05-28 14:52:42

工业网络安全攻击工控安全
点赞
收藏

51CTO技术栈公众号