小编教你流量分析之：NetFlow太少 PCAP太多 网元数据刚刚好。

为什么要将网络可见性锚定到网络元数据？怎样选择和设计算法模式以进一步适应数据湖 (数据湖：集中式存储库，允许以任意规模存储所有结构化和非结构化数据)，甚至适合安全信息及事件管理(SIME)？

而安全运营团队为分析自身数据湖而寻找最佳威胁数据时，网元数据往往落入 “刚刚好” 的类别。

什么意思呢？网络流量分析软件NetFlow提供的数据不全，而且原本是用来管理网络性能的。数据包抓取(PCAP)对性能要求高，且若要保证事后取证调查的精确度，其存储成本也相当昂贵。NetFlow和PCAP之间的权衡取舍令安全人员处在一个难以维系的不稳定状态。

NetFlow：太少了

正如一名前美国计算机应急响应小组(US-CERT)首席分析师所言：很多公司企业向他们的安全团队源源不断地馈送第3层或第4层数据。但这些数据及其非常有限的上下文，到底能告诉企业什么有关现代攻击的东西呢？很不幸，还真不能告诉多少东西。

这就是NetFlow。

NetFlow原本是为网络性能管理而设计的，后来才被用作安全用途。所以，用作取证分析时，NetFlow往往显得力有不逮，缺失了端口、应用、主机上下文等威胁追捕和事件调查的基本要素。

当你需要深入分析连接本身时怎么办？你怎么判断有没有出现指征WannaCry勒索软件主要感染途径的SMBv1连接？或许你能探知主机间存在445端口连接，但若没有协议级细节信息，你怎么深入调查这些连接？

很明显，仅靠NetFlow，你是无法搞定上述问题的。信息不全就是NetFlow的短板。

PCAP：太多了

PCAP用于事后取证调查，可以很方便地进行载荷分析和文件重建，以便确定攻击范围和识别恶意行为。

然而，若进行全面PCAP，最简单的网络都要求有成百上千TB的PCAP数据存储。

因此，就算撇开高昂的性能开销不谈，依赖PCAP的公司企业都不会存储超过1周的数据，而这点时间范围的抓包数据，在公司数据湖很庞大的时候是没什么用的。若考虑到安全运营团队往往直到安全事件发生数周乃至数月后才发现的情况，1周的数据肯定也是远远不够的。

再加上无比巨大的性能降级——对大数据集执行事后取证调查时那慢到令人沮丧的速度，怎么还会有人愿意存储PCAP数据呢？

网元数据：刚刚好

网元数据的收集和存储就刚好达到数据湖和SIEM的要求。

Zeek格式的元数据在网络遥测和价格/性能间取得了恰当的平衡。你可以获得丰富的、有组织的、方便检索的数据，这些数据富含安全监测与调查用例所需的重要流量属性。

元数据还使安全运营团队得以构造能够进一步挖掘数据的查询，执行更深入的调查。随着越来越多的攻击上下文被抽取，构造的查询也越来越有针对性。

而且还没有PCAP常见的性能和大数据限制。与PCAP相比，网络元数据的存储要求至少低了99%。而且你可以选择性地存储正确的PCAP，在基于元数据的取证锁定相关载荷数据后再调PCAP。

管理自有Bro/Zeek部署的风险

是否应该管理自己的Bro/Zeek部署呢？选择自行部署并管理的一家政府机构给出了惨烈的经验教训。

部署初期看起来挺合理的：用内部资源建立一次性小规模部署，然后以其他基础设施实现增量维护，为安全团队提供重大价值。

但随着时间流逝，自有部署越来越难以维系：

首先，很难调整。每个补丁或新发布版本都要求管理员重新编译文件并加以部署。

其次，很难扩展。虽说有部分原因是出于架构决策，传感器默认是不会扩展的——尤其向传感器推送大量分析和处理任务的部署。能以每传感器3Gbps的速度运营的部署都极少见。随着时间推移，这些传感器难以避免地开始丢包，用户最终不得不购置集群以支持所需的处理能力。

最后，跨地域管理分布式传感器军团困难到令人痛苦，特别是传感器配置异构的情况下。熟悉系统的管理员离职时，安全基础设施的关键部分就会处于无人管理状态。

这种两难权衡让很多公司企业都在寻求让自己的安全团队能够更有效率的办法。到底是应该以自我管理的方式人工管理工具(省钱)，还是该专注于成为安全专家和威胁猎手呢？

对选择自我管理方式的公司来说，除了部署上的难题，系统监视、系统日志和前端验证之类的日常运营需求都是沉重的负担。

寻求合作伙伴可以简化此类部署的复杂性：加速部署进度，达成自动升级，消除频繁修复和维护的需求，实现持续系统监视。

这些都是能够让你解脱出来，得以专注安全团队原本职能的默认功能。