这里是普通文章模块栏目内容页
50多种安全产品?供应商言过其实?来看看整合的魅力吧

减少安全工具的数量不仅可以节省开支,还能让你更加安全。

50多种安全产品?供应商言过其实?来看看整合的魅力吧

不同行业报告中的数据可能略有差异,但专家估计,CISO 平均在用的安全产品数量在 55 到 70 个之间。供应商往往言过其实,真正交付的东西跟营销宣传相符的情况几乎没有。所以 CISO 常会陷入尴尬境地——买来让自己过得更舒服点的工具最终却成了自己的头痛之源。

这也算是行业特色了。那么,拥有太多集成不良的工具,不得不加配各方面人手,还只能得到缺乏整体安全风险视图的大量零散数据;面对这种情况该怎么办呢?工具整合似乎是个不错的主意。毕竟,哪位 CISO 不想减少混乱、削减开支和简化流程呢?但是,该从哪儿着手?

从数据质量开始

CISO 都明白,完美的安全解决方案是不存在的。想要覆盖各种安全控制就需要部署多个安全解决方案。但是,CISO 应努力最大化每个解决方案的价值并减少工具的数量。发现漏洞和失控现象的安全工具特别容易误报,其他工具产生的噪音和数据也不少,想要解决无用或干扰数据过多的问题,可以从增加这些输出数据的完整性和准确性入手。

通过确保数据准确性,CISO 可以更有效率地驱动缓解措施部署,知道该最先修复哪里,从中获得安全工具投入的最大投资回报。而且,数据准确性提高了,也就可以使用自动化分析,不用再耗费太多人力跟进不同工具的多个报告过程了。

整合靠拢

CISO 持有太多工具的主要原因,是他们一直在采购,却极少做清理;结果就是功能重叠,而空白长存。

安全工具的整合势在必行,而且无规矩不成方圆,添加新安全解决方案的过程也需要遵循一定的规律。安全工具整合可不是考察每个工具的附加价值和功能不可替代性那么简单。有两个核心基准可以用来确定真正需要的安全工具:首先,每个安全工具都应贴合安全框架中的重大风险;其次,实现的工具应降低公司面临的风险,能够衡量风险降低程度,并能保持这种风险减少态势。

贴合安全框架

基于美国国家标准与技术局 (NIST) 或其他某些机构的标准发展出安全框架,然后针对各安全领域选择一套合适的安全控制,就能获得自身安全态势的完整视图了。该视图能够昭示重点安全领域,有利于着手开发能够达成这些安全控制目标的系统和过程。

仅在开发出这些过程之后,才开始选择能够帮助实现和控制这些过程的工具。每一个工具都应满足该安全控制框架的某个具体需求。控制措施管理着系统修复过程,负责让系统修复及时而完整,在没弄清所有控制措施之前,不应开始挑选工具进行系统扫描。应在了解清楚工具必须达成的目标之后,再选出恰当的工具。

怎么整合

购置安全系统的目标是降低负面影响事件发生的风险(如金融、声誉或监管风险)。设计过程和选择安全工具的时候一定要谨记这一点。实现安全过程和工具时则要保证最终解决方案能做到如下几点:

覆盖公司整个安全界面。举个例子,如果系统漏洞扫描只覆盖了70%的环境,那就有可能不足以降低公司的风险。

提供足够的信息以实施风险缓解操作。例如,若所选系统漏洞扫描器可提供有关漏洞和固有风险的详细信息,但却不提供与公司相关度或该系统拥有者的上下文信息,那这工具/系统就谈不上为充分降低风险提供了足够信息。

持续控制,也就是要自动化控制及监视过程。否则,即便花费时间金钱缓解了,同样的风险还会再次袭来。

想要进一步优化安全工具,还需要解决风险问题。每个系统、每款工具能够降低的风险水平是不一样的。关注那些承担最高风险的安全域,就可以重点拣选并实现合适的安全工具了。

上述基于风险的端到端可持续安全过程(及其相关工具)实现方法,可以帮助公司企业永久性解决以往投入大量工具和金钱仍无法根除风险的安全问题。采取这种方法,长期存在的安全隐患便可一劳永逸。

最后,通过强化数据质量和自动化,再加上工具整合,CISO 气定神闲地加固公司的网络风险态势并非遥不可及。

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

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

【编辑推荐】

通过安全事件看IT产品供应链安全风险

Spring Cloud构建微服务架构:分布式服务跟踪(整合logstash)

Spring Cloud构建微服务架构:分布式服务跟踪(整合zipkin)

Docker安全风险,原来有这么多

怎样选择终端安全产品?这是一份怀疑论者指南

收藏
0
有帮助
0
没帮助
0