让业务与安全贴合:适应业务需求的网络安全指标

安全 应用安全
数据泄露永远不会杜绝,监管规定只会层出不穷。对品牌形象和盈利的潜在影响,令网络安全成为了董事会级别的主要议题。网络安全控制及过程如何适应业务重点的问题变得前所未有的重要。

数据泄露永远不会杜绝,监管规定只会层出不穷。对品牌形象和盈利的潜在影响,令网络安全成为了董事会级别的主要议题。网络安全控制及过程如何适应业务重点的问题变得前所未有的重要。

[[245450]]

安全公司Varonis最近的调查研究显示,业务与安全并未完全贴合;虽然安全团队觉得自己的意见已被听取,但公司领导层却承认他们有听根本没有懂。

问题很明显:安全与业务间语言不通。因为安全处于二者关系中较弱的一方,以业务用语驱动对话的责任自然就落在了安全身上。只要双方沟通顺畅,安全控制与业务重点之间的协调也就会容易得多。

呈现良好的指标是双方都能理解的共同因素,也可作为协同统一的主要驱动力。但事实上,这种情况其实不算常见。

用指标协同安全与业务

要理解如何更好地运用指标来与企业领导沟通,需要知道:为什么指标是必要的?指标如何改进?问题有哪些?代价是什么?

破除语言不通障碍

虽然某些董事可能知道防火墙是什么东西,绝大多数董事却是根本不了解IDS/IPS、SIEM、代理,或者其他什么安全解决方案都有什么用途的。他们只关心公司的风险等级有多高。

CISO虽然了解网络风险,却又未必知道各业务部门什么时候风险最大。同样的,业务主管也不知道不断变化的网络安全威胁会对具体业务风险造成什么样的影响。

安全主管应先更好地了解公司业务层面的事项,以便给出业务主管能够理解的有意义的风险管理指标。这么做可以让安全与业务两方面都能展开多了解对方的过程。业务部门会开始看到安全部门是如何降低风险的,也就会开始指定需要更具体防护措施的其他领域。

此中关键和难点在于找出并呈现推动这一过程的初始指标,安全与业务的分歧也正在于此。CIO领导的IT部门必须维持关键系统的正常运行时间,还要支持数字化转型项目,以便改进业务部门用以完成其业务目标所用的技术。CISO领导的安全部门通常必须维护公司存储、处理和传输的数据与信息的机密性、完整性和可用性。这些部门及其主管倾向于围绕自身战术性职责而非董事会/高管考虑的业务驱动力来提供指标。

安全部门聚焦战术性指标,比如登录、封禁流量、交易计数等等,但这些指标大多反映不出业务目标,或者不是以业务主管能够理解或关心的形式提出的。好的指标因为与业务相关,需与金钱和经营效率挂钩,并能展现安全有效性的趋势模式。真正的挑战和难点正在于此。

问题出在IT和安全专业出身的人往往缺乏基本的业务培训上。2017年的首要管理工具是战略规划。战略规划常常跻身业务主管五大工具之列。但又有多少安全主管足够了解战略规划与执行呢?他们能确保自己的指标对公司的战略目标有所贡献吗?

业务主管没有义务去了解安全。过去很多CISO的败笔就是认为业务需要理解安全。这种想法是十分错误的。因为负责安全的是安全部门,安全才需要更好地去理解业务,以便能够阐明不应用恰当安全防护的后果。CISO才是那个需要去了解业务并理解公司使命目标的人。

这么做值得吗?

接受访问调查的所有CISO都认为,更好地呈现正确的安全指标可以协调安全与业务。事实上,CISO也只有这么做才能让执行管理层理解当前的挑战有哪些,而安全部门又已取得了哪些成果。

除了指标和安全/业务动态,CISO还必须清楚董事会的心理——这就各家公司不一而足了。有些董事会很重视安全,有些则对安全兴趣缺缺。比如说,如果某公司被竞争对手碾压,但这与安全无关,那这家公司的董事会就很可能将安全置于低优先级议题之列。

时间可能由此成为CISO无法控制的问题:指标是应该定期给出,还是应该只在必要是呈现呢?前者可能不必要地占用业务主管过多时间,而后者则会让CISO给人一种厄运使者的印象。

有些CISO认为,董事会不应经常听到安全部门的声音。除非有关键问题或重大业务转型,否则每年上报一次主要趋势、威胁态势演变、战略性安全规划也就够了。

这种观点是少数派。很多CISO至少觉得应经常呈递指标报告以供彰显安全趋势。

然后,呈现风格的问题。一旦有机会向业务主管呈现安全指标,最好别浪费。太多报告跟某些颁奖嘉宾发言似的,单调无聊。报告要么太长(太多细节),要么太多无关紧要的东西。如果报告太烂,只会导致被问及更多问题。

CISO应是销售、市场营销和安全三位一体的专家。安全报告本身应是一份良好的CV,开篇即能抓住眼球,并将受众的兴趣保持到底。最关键的是,报告应回答问题,而不是令董事会质疑该报告。

这一点直击安全指标报告核心。如果报告的目的是展现安全团队的优秀程度,或强调需分拨更多预算的新问题,那基本上可以预期会招致更多问询了。但如果报告的目的是协调安全与业务重点,那这些指标就应更为一目了然不言自明。报告可以略带挑衅,激起业务主管的讨论与批评,但不应招致对报告本身的质疑。

CISO向董事会上呈的指标够吗?

CISO可能目前很大程度上并未交付良好的指标。

指标报告是个经典的鸡生蛋蛋生鸡问题。为交付良好的指标,CISO必须知道业务主管想要的东西;但想了解业务主管的需求,又得通过交付有效安全指标协调安全与业务来达成。

理想状态下,CISO应已进入高管层级。想要交付以业务为中心的指标,安全主管就不应只是简单地向高管汇报,而是跻身高管行列。只有安全主管进驻公司高层,公司才能期望他们的安全方法能反映出对业务战略、方向与需求的深层次理解。

但很不幸,这种可能性很小。监管危机一直持续,因为绝大多数CISO依然报告给CIO。也就是防御协调员向攻击协调员报告。CIO最感兴趣的(比如安全部门防止宕机的频率)往往不是安全应该向业务汇报的(比如为什么会出现威胁,威胁驻留时间是怎么被减少的,减少的程度如何等等)。

不良指标比毫无指标更常见。很多安全项目报告的是安全工具封锁威胁的数量,毕竟解析日志很简单,抛出被阻挡的威胁数量听起来也挺唬人的。但不幸的是,这种数据对高层业务决策毫无用处。

供应商从应用产生指标有所帮助吗?

供应商的应用报告功能若能产出现成的指标,会对公司安全情况有所帮助。一些供应商已经开始尝试这么做了。随着安全态势量化的复兴,供应商也在寻求跨混合基础设施不同部分来提供这一信息。这也是服务供应商和托管安全服务提供商(MSSP)的主要倡议。威瑞森风险报告就是个良好的例子。

但并非所有供应商都赞同提供应用指标,也有供应商认为这不属于自己的负责范围。

问题的症结在于安全部门想要使用的指标和董事会要求的信息之间是否协调良好。应用通常产生大量的细节性数据统计,需要经过很多处理(标准化、聚合和分析)才可以转译上呈董事会。

上呈董事会的指标应传达出与每个受众特别注意的目标相关的信息,并要简洁明了,数量最好不要超过4到5个。

还有企业高管认为,依靠供应商提供自己产品有效性的指标,与让黄鼠狼看管鸡窝无异。而且,也没有哪家供应商的控制措施能够代表企业整体网络安全战略的有效性。

供应商日子也不好过,经常被压价,还被要求按客户需要提供不同形式的安全指标,而且他们的安全预算甚至比很多客户的都小。大多数供应商提供安全指标的意愿越来越强烈,但这些指标到公司企业手上的时候往往经过了精心修饰,不会呈现真正的问题。

有些供应商会要求将日志聚合到单独的报告服务器上,由他们自己的分析软件加以处理,这就可能是个昂贵而复杂的解决方案了。而有些供应商仅提供封装好的高层级报告,并不能供管理员深挖具体问题,限制了报告的有用性。

至于董事会级指标,分析数据必须结合某种形式的成本效益分析,而这种程度的数据几乎没有供应商能够提供。公司企业的安全团队选择供应商时需考察其能否提供数据库驱动的报告,可以方便根据需求加以定制的那种。

供应商需能够,也应该提供其产品性能的原始数据,但CISO总得以与业务主管的关注点直接相关的方式去收集、关联、分析和呈现恰当形式的正确指标。

好指标的要素有哪些?

好的指标需是业务主管重视,且能用于进一步协调安全与业务的那些。那么,好的指标由那些要素构成呢?

1. 将安全指标转化为业务信息需要在关注焦点和报告格式上做出改变

业务部门用记分卡、月度或季度业务审核和关键绩效指标(KPI)来衡量进展及表现。提供给业务部门的安全指标应对业务部门已在开展的业绩评估有所帮助。提供应对业务问题的安全信息,比提供与业务目标无关的技术性信息和日志细节要高明得多。

老话说得好:度量指标应具体、可测、准确、可靠、及时。指标做好了,安全部门和业务部门协调一致奔向公司整体目标;指标做得不好,安全部门和业务部门各自为战甚至互相掣肘,公司目标达成进展缓慢甚或倒退。

东西简单有用就好。采用标准的红/黄/绿指示器可以很快向董事会揭示风险、合规和监管的协同程度。图表则可用于显示风险随时间减小的趋势和整体框架整合情况。四象限图能快速展示顶级风险、需引起管理层注意的问题、重大事件,以及进展中的重要项目。总之,简洁明了。指标不需要附带太多技术细节,但要有统计数据,并与业务/信息安全协作关系相一致。

可以参考个人信用评分(FICO)。比如说用百分制的一个评分来反映企业安全与合规态势。当然,这其中应避免掉入一叶障目不见泰山的坑。不妨考察黑客渗透和侵害公司的方式,藉由同样的方法得出安全评分。你首先发现并分类各种资源,既有现场的也有云端的,然后评估各自面临的内部和外部威胁。基于该评估,你识别出系统中的弱点,再根据现有控制措施评估这些资源。

最终结果,就是反映公司当前网络状态的总得分。修复识别出的弱点可以提升得分。其他可以评分的因素还包括数据泄露的概率及其预期影响。后一个得分可以映射进CIA模型,也就是“机密性、完整性和可用性”模型。

2. 趋势是非常重要的一方面

你能否由平均修复时间的大幅降低拿出每个业务部门对公司固有风险减小程度的月度统计数据?董事会关心的指标类型是这种,而不是防火墙阻挡了多少攻击,也不是基础设施漏打了多少补丁,更不是其他什么靠巨大的数量唬人的指标。

这种单纯的大数指标或许在操作层面上对信息安全人员有所帮助,但在董事会层面最好还是说些董事们关心的事——董事会有责任保护公司业务平稳发展。报告给董事会的指标要与这些公司目标相一致。用董事会能理解的语言表达这些指标,比如对业务的影响而不是对技术的影响,并确保他们知道安全部门的诉求是什么。千万别什么诉求都不提就匆匆结束董事会会议离场。

3. 安全报告还应是个持续的过程,及时报告安全趋势而非静态数据

比如说反映年度趋势的逐月环比报告。这样董事会才可以清晰地看出做得好的地方、有所改善的地方,以及还需要后续处理的重点问题。清晰的可视化展示和路线图可以让董事会明白公司安全形势,而不是看起来一脸迷惑不解的样子。

展示中应包含具体的指标,比如威胁驻留时间、横向移动、重复感染、网络覆盖和响应时间。

这些问题可以综合起来形成以业务为中心的指标。

比如说,风险可见性占比(处于安全管理之下的系统所占比例)就是个非常重要的指标。不仅仅要报告你能看到的东西,还要报告因为技术和时间限制而还没看到的风险占比是多少。另外还有实现了某层级防御的受管系统所占比例。二者间差异很大,即便后者数据很棒(受管系统几乎都实现了某种防御措施),如果前者情况糟糕(公司所有系统中只有一小部分处于安全管理之下),公司风险依然很大。

公司信息供应链和运营风险可分为3级。首先,从威胁追捕团队的结果来判断公司当前是否遭受网络攻击,攻击的规模有多大?其次,该网络犯罪被扑灭和控制最快得要多久?最后,公司是否遵从了行业和地区的强制合规标准?如果没有合规,原因是什么?

不同指标应综合到一起以揭示公司的整体安全态势。呈现威胁形势和公司响应随时间的发展变化也很有用。这能让通常不是网络安全专家的公司高级管理层体会到为什么安全是以业务为中心的,让他们觉得安全值得持续投资。CISO需将安全洞见提炼成非技术受众也能理解的东西,这些受众往往对“为什么”更感兴趣,而对“是什么”兴趣缺缺。

信息孤岛是必须要杜绝的东西。可以设置一个新兴威胁仪表板,在一个地方纵览所有安全相关事务,方便快捷地查看有哪些东西需要多加注意,应添加哪些控制措施。

但在最后的分析中,最好的指标展现的是网络安全项目在达成关键业务目标上的有效性。

要点

报告给业务主管的信息安全指标没有固定的形式,各个行业间差异很大,同行业的各个公司之间也有所不同。指标好不好,取决于关键业务驱动力。

信息安全必须了解业务。CISO不能期待业务主管来理解安全。指标的目的就是要解释安全是怎么支持或进一步支持业务重点的。为做到这一点,CISO必须了解这些业务重点。

此中存在的问题是,这种了解最好来自于成为整体业务领导层的一部分——极少发生的一种情况。在一些开明的案例中,CISO至少在董事会层级是能发声的;但大多数情况下他们的直属上级依然是CIO,而CIO有他自己异于CISO的关注重点。

指标问题必须解决。指标问题解决得好,可以获得极高的回报,至少可以享有更有效的安全、更好的盈利,可以在必要的时候争取到所需的预算,以及在董事会层级刷出更大的个人存在感。如果能够在重要的位置提供恰当的防护,安全基本上也就成为了业务驱动力和盈利增长点,而不再是众人眼中空耗公司预算的资金黑洞。

如果没有良好的指标,安全和业务没办法协同统一。没有这种协同统一,安全部门就是救火队的角色,而业务时刻面临风险。

Varonis最近的调查研究原文地址:

https://www.securityweek.com/continuing-problem-aligning-cybersecurity-business

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

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

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

2011-05-13 13:24:02

2018-12-26 05:05:36

业务驱动安全绩效指标KPI

2015-12-14 13:14:34

网络安全华为

2020-07-30 17:54:35

2011-12-28 10:59:19

2011-12-29 13:19:02

2018-07-02 14:19:00

2020-07-30 17:49:26

2020-07-27 10:36:23

网络安全云安全技术

2018-12-17 10:16:31

2013-06-28 14:30:04

2013-01-15 15:33:43

2021-07-12 14:20:43

工控安全互联网安全网络安全

2013-11-07 09:47:16

2020-07-30 18:01:38

网络安全网络安全技术周刊

2019-02-28 22:47:06

云计算数据安全企业

2013-01-06 09:39:05

2011-06-24 10:23:10

云计算容量管理BMC

2022-07-03 16:33:38

网络安全漏洞微软

2022-06-30 05:26:41

网络安全业务
点赞
收藏

51CTO技术栈公众号