公司该怎样运作风险和安全项目？更具体点，大数据时代，公司该怎样运作其威胁情报处理？
很多公司貌似认为自己知道打开他们企业王国大门的钥匙是什么，以及入口点位于哪里。然而不幸的是，惨重的教训会让他们很快明白最严重的数据泄露经常发生在别的地方。
比如，银行会关注意他们取款机活动，却会忽略大型主机中通过的微小警告信号。而忽视了这一点，他们的核心业务就会置于风险之中，成为黑客的首选攻击目标。
要清楚应关注什么，就得收集那些可以被分析的数据，并把关注点放到执行分析上。然而，如果公司不持续收集并分析完整的数据流，他们就不会成功——成功要求的不只是有限时间窗口内的一段快照。要收集的数据必须包括恶意活动发生之前、过程中及之后的。
不令如此，还需要囊括来自整个网络内部、每个终端，甚至网络外部公开来源的数据。否则，应急响应会非常有限。
有效事件响应需要环境支持
有能力对事件做出响应就是威胁情报大展身手的地方。而这，需要环境支持(上下文)——原始数据之外的信息。上下文可被用于识别高级或隐蔽攻击，甚或数据泄露——还能教你怎样做出最佳反应。
想要恰当地管理安全事件，公司不仅要收集数据，还需要实时分析数据——然后存储数据以便以后能用于关联新的实时数据。挑战在于，存储数据需要资金——而且，数据管理和使用可能很成问题。
现实情况是，想分析日志的安全团队受制于决定记录什么以及从哪些系统中记录日志的开发者。这些日志细节常常在系统开发的时候就内置(或者更确切地说，被排除)于系统。
完整抓包揭示问题实质
甚至，安全日志还仅仅是冰山一角。问题的实质隐藏在从整个网络中抓取的完整数据包中。越过这个只拿日志的障碍，走向网络数据包抓取，让公司背上了安全数据的负担——另一大挑战：
安全数据不是大数据。它是病态肥胖的数据。
——崔维斯·史密斯，著名安全公司Tripwire高级安全研究工程师
通常，数据存储最佳实践是存30天的数据流量——尽管有些行业策略和某些政府规章要求更多“如果安全团队纯粹生活在警报模式里，无力去分析上下文，则会忽略掉很多。
有时候这不仅仅是一个存多少的问题，还会涉及到客户从他们的安全管理项目中获取所需有多难的问题。安全团队要么没有警报，要么警报太少，还有一种情况，就是严重的警报疲劳。
要考虑的其他数据来源
即要绝对捕获你的日志数据，但也要寻求超越日志并组织一些企业自身内部网络的反馈，还应该将会话联系在一起以捕获数据包流，最终执行一个完整的数据包抓取。
此外，还应该考虑那些可能不会被列入传统安全数据范畴的外部数据反馈。。如社交网络上的活动、求职活动和员工在公司设备和网络中操作的其他数据源。
某些数据来源可能看起来不像安全数据，但可以大幅改变安全数据上下文，并为公司审查他们的风险分析提供一个全新视角。当然，想用好威胁情报，反馈必须可信且建立在可靠来源基础上。这包括你自身内部的反馈。大量应用会产生很多看起来非恶意的内部数据流，这些内部数据大多数是让业务团队得以开展工作所用的共享数据。这种数据反馈及反馈的质量也是不容忽视的。
这些内部专用的网络通信通常会被只监视入侵和渗透检测系统日志的行为给忽略或无视掉。究其原因，是因为这些数据流通常是在网络内部横向移动，从不流过入侵监视系统，也不穿越边界防火墙。
入侵和渗透只发生在设备流量进入或流出公司网络的时候。同样，命令与控制通信也可以通过使用外部临时站点逃避网络检测。而大多数时候，在这一层发现问题就已经晚了。
(责任编辑：安博涛)
