一、引言

    单纯的防御措施无法阻止蓄意的攻击者，这已经是大家都认同的事实，应对挑战业界有了诸多方面的探索和实践，而其中最有趣的就非安全分析莫属了，围绕着安全分析展开，我们可以看到大数据、安全智能、情景感知、威胁情报、数据挖掘、可视化等等，因为这些都是安全分析师手中的武器。

    二、安全战略思路的变化

    坏的消息是，入侵总会发生，再强的防御也难以做到御敌于国门之外，攻击者总会进入到你的网络中；那么好消息就是入侵和破环是两回事，虽然也存在入侵开始到实际损害发生之间时间窗口很短的情况，但是我们也还是看到，大多数入侵如果想达到目的，需要较长的时间，特别定向攻击和APT攻击。那么如果安全团队可以在攻击者完成使命之前阻止其活动，就可以做到这点：我们有可能遭受入侵，但可能不会遭遇破环。

    据此有效的战略是尽可能多的进行实时防御，来防止入侵的可能，同时配合积极的检测（Hunting）与事件响应来避免出现破环，或者最大限度的减少破坏的影响。

    由此我们知道，传统的安全产品没有过时，我们还是需要4A，需要防火墙、IDPs以及AV这些不同的产品，形成一定的防御纵深，阻止随机性的攻击（通常追求机会，被选中往往是因为展现了易被利用的漏洞），并且延缓攻击节奏，扩大检测和响应的时间窗口。这是一切的基础，如果没有这一步，后续的检测和响应也就缺少了根基，在现实中无法实施。

    从这点上说，个人也不赞成将某些针对特定组织的攻击都归属于APT范围，如果它是一些传统的安全措施就可以防范的。这可能误导某些组织，在缺乏基本防护措施（产品、组织、制度等）的情况下，盲目的追新求异，达不到切实的安全效果。

    三、以威胁为中心的安全理念

    实时防御是以漏洞为中心的，基于漏洞的签名检测机制有着较高的准确性，可以用以进行自动化的阻截。但当基于已知威胁的签名机制不能检测针对其的高级别威胁时，我们就需要转化思路，因此积极的检测和响应则是以威胁为中心，它不再强调单点的检测，也不再单纯的追求告警的精确性，它促使你从面上去着手，将若干的点关联起来，以数据为驱动来解决问题。在整个过程中（数据收集、检测、分析）都需要以威胁为中心，如果丢掉这个中心点，单纯的追求数据的大而全，则必然达不到效果。以威胁为中心，用数据来驱动安全，是检测APT类型威胁的有效手段。

    需要强调的是，以威胁为中心聚焦在数据收集，但并不强调数据的大，而是价值的高，认为它是一个动态的、周期性的过程，随着威胁的变化，以及分析能力的改变，数据收集的范围将会产生变化的。

    四、数据收集

    古语言“磨刀不误砍柴工”，这句谚语非常适合来描述数据收集的重要性。但如果我们单纯的强调全量的数据，会是什么样子？通过简单的数据计算，我们可以知道监控1G的数据流量，如果采用PCAP文件格式存储完整的内容数据，那么一天就需要大约10T的磁盘空间。如果我们要保留90天的数据，再考虑备份、数据索引等需要的空间，哪会是多少？如果你需要监控的网络流量不止1G，如果还需要考虑主机及业务应用的日志？庞大数据的存储和维护固然是问题，还需要考虑到当盲目收集数据之后，也许这些数据的命运是永远躺在磁盘中，仿佛从不存在，更甚者还会给后续分析过程带来混乱、不确定性和低效率。

    因此明智的问题是“我从哪里获得所需要的数据？”，而不是“我需要对该数据提出什么样的问题？”Gartner在《Security Information and Event Management Futures and Big Data Analytics for Security》一文中也特别的强调“分析的意识和探索数据的欲望”，认为这才是大数据安全中最关键的成功标准，首先学会问问题，而不是盲目收集数据或者是急于建立一套Hadoop大数据平台。

    五、数据种类

    以威胁为中心进行数据收据，自然包括威胁情报的收集，在之前的《小议威胁情报》中已有涉及，后续有时间也会就如何建立组织的威胁情报平台整理自己的观点和大家共同讨论，这里不再多言，而专注于组织内部的数据收集。企业内部数据一般需要考虑一下几个种类：

    1.环境业务类数据：包括资产及属性（业务、服务、漏洞、使用者…）、员工与账号、组织结构等，这类数据也会被称环境感知数据、友好类情报等。此类数据往往难以从机器中直接获取，但对安全分析会有巨大的帮助，往往要依赖安全体系建设而逐步完善；

    2、网络数据：包括FPC（Full Packet Capture，一般是PCAP格式）、会话或Flow数据，PSTR（Packet String，这种数据格式包括指定的协议头部内容，如HTTP头数据）。PSTR数据大约是FPC的4%左右，而Flow数据则是0.01%。PSTR是大小更容易管理，并且允许增强可见性的一种数据类型。

    3.设备、主机及应用的日志：它可以包括诸如Web代理日志、路由器防火墙日志、VPN日志、windows安全及系统日志等，不同来源的数据类型在大小和实用价值上都不同。 4.报警数据：检测工具基于其配置发现异常，进而生成的通知就是报警，通常的报警数据来自IDS（主机或网络）、防火墙、AV等安全设备。依据环境和配置，日志的数据量可以有很大的变化，但通常小于PSTR。

    六、ACF方法

    那么如何确定需要采集用以进行安全分析的数据呢，这里介绍一个ACF（Applied Collection Framework）方法[1]，它可以帮助评估哪些数据应该是收集工作的重点。ACF不是一个纯技术的手段，需要安全团队从其他业务部门收集早期的信息，并配合完成整个工作。它由四个阶段组成：定义威胁、量化风险、确定数据源、筛选聚焦。

    1. 定义威胁：这里不是泛泛而谈，如竞争对手、脚本小子等，需要确定针对具体组织的具体威胁。它应该是“发生什么样糟糕的事情，会影响到组织的生存”这样的问题，并且答案应该来自领导层或者是被其认可。一旦关键业务安全需求确定了，就需要深入挖掘可能的威胁，通过研究网络基础设施及相关的业务流程，明确相关研究、生产、存储、加工、访问等相关环节，进而明确可能的入侵及破坏方法。

    2.量化风险：一旦潜在的威胁名单确定，就需要考虑优先级，一般实现的方式是通过计算威胁影响和概率的乘积，得到每个潜在威胁的风险。虽然这种方法可以提供和威胁相关的量化指标，但毕竟是主观的。为保障评估确实符合实际，往往需要一组人来参与量化风险的过程，有些机构还会在这个过程中引入第三方的网络渗透测试人员，共同参与完成这个过程。

    3.确定数据源：在这个阶段确定可以提供检测和分析价值的主要数据元，从具有最高风险权重的技术威胁开始，考虑可以从哪里看到威胁相应的线索、证据。比如考虑关键文件服务器的数据泄露威胁，应该确定服务器的架构、网络位置、具有访问权的用户，以及可以获得数据的其它途径。根据这些信息，得到相应的数据源清单。

    4.筛选聚焦：在最后的阶段你需要选择最需要的数据源，这是技术上最深入的步骤，需要评估每个数据源以评估其价值。往往有一些数据源需要很高的存储空间，它提供的价值和处理管理的开销相比，可能不值得收藏。组织必须考虑成本/效益关系，从成本的角度看，这种分析应该考虑到硬件和软件的资源，例如维护产生的人员组织成本，数据存储资源等。可以评估有问题的数据源在分析过程中可能出现的几率。考虑需要到类似这样的程度：哪些类型（源目的地址、端口协议）的PACP包需要捕获，那种windows日志（如登录成功、登录失败、账号创建、文件权限变更等）是最重要的需要保留。

    通过这样的方法，你可以通过直接和业务目标挂钩，以及对业务连续性的威胁来证明需求的合理性，这样也可以较大限度保证之后在基础设施建设上的投入。

    正如之上曾经提到的，威胁为中心的方法强调周期性的过程，需要明白，永远不会完成数据收集的工作，当你做了更多的检测和分析的工作，当网络逐步扩展，需要重新评估你的收集计划。

    七、基于威胁情报和攻击链的方法

    ACF虽然是一个经过实践验证的方法，但是也有自身的不足，特别是缺乏实践经验情况下，往往集中在入侵的后期阶段相关数据收集，存在检测纵深不足，缺少冗余的响应时间等风险。这时可以参照一种基于威胁情报和攻击链的方法，用来验证、完善数据收集计划，此方法来源于David J. Bianco的关于情报驱动的企业安全监控的讲演（PPT、视频）。

    这种方法大体步骤如下，对更详细内容感兴趣的可以去参考他的PPT及视频：

    1.以攻击链为横轴，检测指标（参考之前的《小议威胁情报》）为纵轴，完成对应的表格，体现在攻击的各个阶段可以利用的相关数据；

    2.基于不同检测指标对黑客攻击的影响程度，给出评估；

    3.基于有效检测APT类型攻击而不被大量报警淹没，给出评估（参见下图）；

    4.基于现实中可达的工具能够实现，给出评估；

    5.综合以上3项评估的数据，确定数据收集计划。

    这种方法也是一种周期性的活动，需要根据新的威胁情报和分析工作的进展而不断修订，个人更倾向于认为它是对ACF方法中步骤3、4的具体化操作指南，ACF中的步骤3对应着这里的步骤1，而ACF的步骤4对应了这里的步骤2-5。

    八、小结

    大数据安全分析的第一部分内容就写到这里了。我们反思了当前威胁形式下安全理念的变化，我们需要以实时防御为基础的积极检测（Hunting）和响应来避免出现或者缓解可能的破坏活动，它以威胁为中心，侧重于数据的收集。在考虑数据收集计划时，我们可以参考ACF方法，以及基于威胁情报和攻击链的方法，确定最佳的成本/效益。完成了初步的数据收集之后，就是安全分析师体现风采的时间了，我们将在下一篇文章来讨论安全分析的具体工作以及相关分析平台产品的话题。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。