A-A+

复杂是安全的大敌

2015年04月01日 安全百科 暂无评论 阅读 819 次
复杂是安全的大敌

作者:Joshua Goldfarb 火眼公司信息安全专家 拥有超过10年的安全运营中心(SOC)建设和运营经验。

我们可能都听过“复杂是安全的大敌”这句话,但我们可以从这个说法里学到什么,用于改善我们的安全状况?大家可以从多个角度来对这个说法进行阐释,我还是想从安全运维和事件响应的角度来审视它。

确保数据收集和分析简单化

大多数企业为其网络配备了诸多设备,以收集许多不同形式、高度专业化的数据。比如说,一家企业可能在收集NetFlow数据、防火墙日志、DNS日志及其他各种专业化的数据。这带来了源源不断的各种不同类型和格式的数据,因而让运维工作流显得错综复杂、扑朔迷离。遗憾的是,进行分析或事件响应时提出的第一个问题往往是“我从哪里获得需要的数据?”,而不是“我需要对数据提出什么样的问题?”

除了这些数据的多样性和复杂性外,它们带来的数据量常常让企业不知所措。这些巨大的数据量导致较短的保留期和较长的查询时间。综上所述,这场完美风暴带来了一个非常现实的运维挑战。

安全数据收集

幸好,企业组织可以求助于数量较少、更广泛的数据收集技术来应对这个挑战,这类技术提供了所需的可见性,同时又大大降低了复杂性和数据量。继续说说上述例子,企业可以考虑采用单一的第7层丰富元数据源,以代替许多不同的高度专业化的网络数据源。

确保检测简单化

维基百科给攻陷指标(IOC)所下的定义是“网络上或操作系统中所观察到的异常。高可信度的异常意味着计算机入侵。”相关的情景信息也通常与异常一并包括在内,可以帮助企业合理利用攻陷指标。除了其他信息外,情景信息通常包括关于指标与哪个攻击阶段有关的信息。攻击阶段可以分为三个主要类别,每一类包含一个或多个攻击阶段:

  • 感染前:侦察、利用漏洞、重定向
  • 感染:载荷交付
  • 感染后:指挥与控制、更新、投放、缓存和渗漏

众所周知,许多企业为数量过多的误报和警报队列中过低的信噪比而苦恼。企业可以从几个不同的角度来对待这个问题;实际上,本人之前写过这方面的相关文章。另一种此类方法就是“抓重点”(go for the money shot),它可以与其他方法结合使用。

到某个时候,企业想留意并警报某个令人关注的攻击、入侵或活动时,该企业就需要为此选择一个或多个攻陷指标。“抓重点”需要为某个令人关注的攻击、入侵或活动,选择最精确、最可靠、最不容易出现误报的一个或多个攻陷指标。比如说,如果我们看一下一个典型的基于Web的重定向攻击,它可能涉及以下几个阶段:

  • 危及合法的第三方网站,重定向至恶意攻击网站
  • 从恶意攻击网站钻系统的空子
  • 交付恶意代码
  • 指挥与控制,以及其他感染后活动

虽然我们可以在所有上述四个攻击阶段来使用攻陷指标,但是在前三个阶段来使用攻陷指标带来了一些挑战:

  • 遭攻击的第三方合法网站可能数以百万计,这意味着我们仅仅为了在这个阶段识别攻击,就需要数以百万计的攻陷指标。此外,无法保证企图的重定向会成功(比如,如果它遭到代理系统的阻拦)。不成功的重定向意味着没有人企图钻空子。换句话说,这是误报。
  • 钻空子并不总是成功;正因为如此,警报企图钻空子的行为常常会生成成千上万的误报。
  • 如果我们看到恶意载荷被交付,这肯定值得关注。但是如果恶意载荷并没有成功地传送、安装、执行及/或持续,情况会怎样?当然,除非我们看到控制与指挥或其他感染后活动,否则对于系统是否受到了感染所知甚少。

另一方面,命令与控制及其他感染后活动总是出现在感染后。这意味着,如果我们能为这个攻击阶段提炼出一种精确而可靠的攻陷指标,就能在恶意代码感染后立即有所发现,误报率非常低。很显然,能防止攻击永远是最好的,但我们都知道,并非永远防止得了攻击。下一个最好的选择就是及时而可靠的检测。

运维的简化

上世纪50年代,战后的美国人开始从城市向郊区迁移,兴建了新的基础设施,以服务迁徙的人口。基础设施为居民提供了50年的优良服务,到2000年水管、电力线及其他基础设施的实际使用寿命已到头。这时人们很快意识到,虽然已分配了用于建造和部署基础设施的资金和资源,却没有分配用于基础设施长期运维的资金和资源。换句话说,想修复或更换老化的基础设施,就离不开运维;但是运维所需的资源不得不从别处寻求。
在信息安全领域同样也是这种情况。新业务需求出现后,我们常会部署新安全技术以满足这些需求。企业在估算总体成本时却常常会忘记运维因素。让我们就换个角度来考虑。每项新安全技术都需要去合理地部署、运行和维护。如果部署一项新安全技术就增加人手,这种模式就没问题。但安全人士都知道,人手很少能随新业务需求而增加。这给企业带来很大挑战。

运维成本(包括合理部署、维护和运行技术所需的人力资源)是技术生命周期过程中不可忽视的一块重要成本。运维成本在技术的总体成本中占很大一部分,可是它又常常被忽视或被低估。为了竭力降低总体运维成本,并且加强上面讨论的数据收集和分析,有必要花点时间考虑每一项技术的目的。这是用于专门目标的专业技术吗?我是否可以通过使用单个、通用技术,来保有数个专门技术的功能和可见性?

如果这两个问题的答案是肯定的,那就有必要考虑一下借助我所说的“缩架法”(shrinking the rack)对众多安全技术进行整合。缩架法是一种很好的选择,只要它没有给安全运营带来负面影响。较少的专业安全技术意味着在合理部署、维护和运行方面只需较少的资源。这反过来意味着降低了总体运维成本。较低的运维成本始终是个有力的激励因素。

我们可以将简化这个概念直接运用到安全运维和事件响应上。我们可以从这个话题悟到好多经验,而本文仅仅触及其中几个经验。虽然“复杂性是安全的大敌”是个流行语,但如果我们更深入一层地分析和探究,就会发现我们能从这个概念学到好多东西。

标签:
Copyright © 互联网世界 保留所有权利.   Powered by www.zhangjinpeng.com.cn 网站地图   粤ICP备13066957号-2  
内容说明:本站内容及数据部分来自互联网及公开渠道,如有侵权请及时联系我们,本站将在第一时间删除相关资源。

用户登录

分享到: