OCSF 是安全数据湖民主化的关键吗？
检测并阻止当今的网络攻击需要跨许多不同的安全工具进行协调。不幸的是，团队花在统一这一安全日志数据上的时间和资源对于执行必要分析，根除潜在攻击而言是一项无法接受的成本。开放式网络安全架构框架 (OSCF) 项目旨在改变这种情况，以便团队可以花更少的时间进行分析，进而用更多的时间保护他们的环境。但让我们看看是什么让这种新方法如此重要和及时。
为了让安全日志事件数据有用，每个日志必须有一个架构，以便定义日志中用于搜索、聚合或检测的字段。例如，一个网络连接日志可能有一个发起连接的源 IP，和一个接收请求并提供响应的目标 IP——架构中可能有诸如 src 和 dest 这样的字段，以便安全分析人员知道他们可以针对这些字段进行查询。
然而，对于这些架构，日志类型或工具几乎没有统一的标准。使用同样的例子，CrowdStrike 可以从网络日志中提取 IP 源作为 IP，目标地址作为 RemoteAddressIP4。PAN 防火墙可以调用源 IP src 和目标地址 IP dst。有些日志是完全非结构化的，只能从日志事件内部了解日志格式和 IP 地址位置来确定源 IP 地址和目标 IP 地址。
通常情况下，分析人员需要跨大型日志子集进行查询。例如，他们可能想知道所有的网络日志中是否有任何主机连接到特定的 IP 地址。因此，我们不仅需要每个日志类型的架构，还需要这些架构达成一致。如果有一种更好的数据摄取和分析方法，且人工工作量更少就好了！
日志标准化的挑战
到目前为止，Salesforce 使用一个称为“事件数据字典”(DDI) 的复杂内部解决方案来解决这个问题，该解决方案列出了每个日志中的每个字段，并且我们已经定义了数据字段提取规则 (DFE)，这一规则可以解析日志并将字典强制用作一种架构。在检测和响应架构中，这个过程发生在一个称为“归一化处理器”的系统中。
进行归一化处理之后，所有日志（包括之前的非结构化日志）都会具有相同的架构和一组我们可以查询的字段。我们可以在 CrowdStrike 日志中提取 RemoteAddressIP4 并将其重命名为 IPDestination，同样，我们可以将 PAN 日志中的 dst 转换为 IPDestination，如果分析师想通过查询所有日志并询问 where IPDestination ==[…] 来查看特定 IP 是否连接，只需编写查询语句即可。
理想情况下，这种方法很棒！分析人员可以进行搜索。但日志归一化也会带来一些特有的挑战：
- 数据字典中有数百个字段，其中许多字段为空字段，这样就会浪费大量空间。
- 我们得到一个新的日志类型时，字段可能与我们之前的定义不一致，从而产生奇怪的边缘情况（例如，user、username、useremail 对于不同的 logtype 而言意味着不同的元素）。
- 我们必须手动解析每个新的 logtype 或 sublogtype，作为通过编写正则表达式或解析规则引入新日志源的一部分。
- 任何对日志结构的更改、字段的添加或替换都可能导致现有规则无法解析相关字段。这是一个严重的数据质量问题。
- 此外，我们没有一个很好的方法来对规则进行大规模验证或跟踪。这些规则很可能是重复的；规则集的维护和更新具有很大的挑战性，因为规则的弃用会带来巨大的风险。这可能导致新规则覆盖旧规则功能的回归问题。
所有这些工作的成本都会增长。团队的主要精力不是放在检测事件并对其进行响应上，而是花时间将这些数据进行手动归一化处理，以便满足先决条件。
OCSF Adoption
开放式网络安全架构框架 (OCSF) 在 BlackHat（8 月 22 日）上被公开宣布为一项开放是架构标准，这是一个前所未有的项目，是一项跨多个网络安全来源进行数据归一化的重大举措。该框架旨在提供一个简化的、与供应商无关的分类方法，以帮助所有安全团队在无需进行耗时的预先归一化处理任务的情况下实现更好、更快的数据摄取和分析。
我们的目标是建立一项开放标准，符合现有安全标准和流程的任何环境、任何应用、任何解决方案提供商都可以采用这一标准。OCSF 是一个类似于我们的数据字典方法的开源框架，它旨在解决本文开始提到的各种问题，它还可以通过根据分析人员的使用定义待架构化处理的字段子集来解决我们的方法引起的痛点。
我们的首席信托官 Vikram Rao 向我们表示 ：“每个公司都面临着快速数字化转型的迫切需要。但构建一种安全状态，以满足互联网规模的数字化信任水平可能是一项重大挑战。OCSF 等新标准可以降低安全团队的复杂性，使他们能够专注于威胁分析和攻击预防等更重要的工作。”
测试运行
Salesforce 检测和响应工程团队对 OCSF 进行了评估，考虑了将此架构应用于 Salesforce 生成的日志，以及对现有归一化方法进行调整，以便使用 OCSF定义的架构输出日志，而不是来自事件数据字典的自定义架构。
为了更好地理解 OCSF，我们首先进行了一次演练，将假想的 Salesforce 安全检测事件转换为 OCSF 格式并对其进行了评估。下面是 DDI 格式和 OCSF 格式事件的截图。
在进行这项演练和探索 OCSF 架构的过程中，我们发现了一些可能可以为我们所用的有趣字段；例如，修复对象，该字段有助于链接知识库文章，描述，在对事件进行分类时，该字段对下游分析人员很有帮助，还可以帮助他们采取进一步的行动。
我们快速启动了跨内部团队的工作和原型设计，进而对我们内部应用程序日志 sfdc_applog 最终向 OCSF 格式日志生成器的转换进行评估。我们需要后续的协作者，以便推进项目。如果您想和我们一同开展这项工作并使用此架构实现自有日志的标准化，可以[按此处]开始并获取 OCSF GitHub。
特别感谢
开放式网络安全架构框架项目旨在简化供应商中立框架中的数据分类，以帮助安全团队减少对数据进行归一化处理的时间，并将更多时间用于防御，这一项目值得大家为之喝彩。OCSF 项目有赖于 Cloudflare、CrowdStrike、DTEX、IBM Security、IronNet、JupiterOne、Okta、Palo Alto Networks、Rapid7、Salesforce、Securonix、Sumo Logic、Tanium、Trend Micro 和 Zscaler 的贡献。
看到这样的形势，Salesforce 深感欣慰，能够成为 OCSF 的早期采用者，我们也深感荣幸。我们将最为重要的前几个 logtype 事件转换为 OCSF 的早期演练是一个很好的开端，并帮助不同的内部团队了解了这一框架及其发展情况。鉴于 OCSF 是一个开放标准，又是安全行业的协作成果，有多个相关方采用该标准并帮助其发展，它有可能帮助所有组织的安全数据湖实现民主化。
最后，为了使 OCSF 发挥最大的作用，我们需要云提供商和安全供应商以 OCSF 模式来对齐和提供日志。如果您的业务属于这一领域，请帮助我们打破这种界限并使其成为安全领域的新标准！