网络安全数据工程：数据富化

安全事件的发生很少是因为团队缺少足够的告警或日志数据。相反，安全事件往往发生是因为有人 (或某些工具) 忽略了隐藏在大量噪音中的关键事件序列或告警。处理来自几十到上百个来源的遥测数据很快就会变得难以管理。

想象一下，一个 SIEM 系统不断被来自不同数据源的大量原始日志淹没，却没有足够的富化来将它们联系起来。每个单独的事件本身无法描绘出这些活动对你组织意味着什么的全面图景。你可能注意到一个 Lambda 函数运行得比平时多一些，但却错过了攻击者是如何窃取了开发人员的 IAM 密钥，并设置了一个模仿你生产服务的通用名称的隐蔽 Lambda 函数，在正常工作时间使用定时的 GetObject API 调用从 S3 存储桶安静地复制敏感数据到他们的外部服务器。这些 S3 请求看起来像是来自预期 IP 范围的合法授权流量，经过了适当的身份验证，所以没有适当的关联和上下文，它们只是埋藏在数百万其他日志中的常规日志...直到你在后期意识到有些不对劲。

检测威胁的数据通常已经存在于你的工具中，只是分散在各个不相连的日志中，等待有人 (或某些系统) 将这些点连接成一个清晰的攻击故事。

当安全团队花费数小时调查误报并为每个"严重"级别的告警寻找上下文时，他们会错过实际威胁并面临精疲力竭的风险。解决方案不是更多的数据，而是上下文化的数据和自动化，这最终帮助安全团队更快地做出更好的决策并阻止漏洞。

在这篇文章中，我们将介绍：

什么是安全数据富化
常见的富化来源和类别
AWS CloudTrail 事件富化示例 (前后对比)
如何、何时以及在哪里应用富化

什么是安全数据富化？

简单来说，数据富化是为原始安全事件、发现和告警添加相关上下文。它帮助回答以下重要问题：

谁访问了什么？
执行了哪些操作？
受影响资产的重要性如何？
这种行为是否正常？
潜在影响是什么？
这是否与已知的威胁活动相关？

为什么这很重要：没有富化，分析师需要花费数小时手动调查告警，在大量工具之间跳转，复制粘贴 IP，交叉检查用户名，并尝试拼凑行为模式。这是一个巨大的时间消耗，并导致告警疲劳 (误报) 和错过威胁 (漏报)。富化通过将关键上下文引入日志数据而不是让分析师去寻找上下文，从而改变了这种状况。

注意：在整篇文章中，我们提到了不同类型的富化，包括对告警、日志、发现和其他遥测数据的富化。实际上，你可以富化几乎任何类型的遥测数据，因此我们尝试涵盖了许多不同的富化方法、用例、来源和限制。

常见的数据富化来源

外部上下文：

威胁情报：将 IP、域名和哈希映射到已知的恶意行为者、活动或C2服务器 (例如 VirusTotal, Recorded Future, AbuseIPDB)。
漏洞数据：将 CVE 与可利用性、补丁状态和实际严重性联系起来 (例如 GitHub Advisory DB, VulnCheck, CISA KEV)。
地理位置：将 IP 地址解析为物理位置、ASN 和网络信誉数据 (例如 MaxMind GeoIP, Shodan, Tor Exit Lists)。
MITRE ATT&CK 映射：根据已知攻击者的战术和技术对事件进行分类 (例如 ATT&CK 框架、供应商映射)。

内部上下文：

资产上下文：将 IP 和主机名链接到设备类型、所有者以及它对业务的重要性 (例如 CMDB, AWS Config, 云清单)。
身份和会话上下文：将用户与角色、权限、部门和典型行为模式相连接。还包括身份验证详情，如登录方法、MFA 使用情况和会话 ID (例如 Okta, Entra ID, Workday)。
业务上下文：将系统和数据映射到业务流程、合规要求、风险级别等 (例如内部数据和资源标记、GRC 工具)。
行为基线：通过将当前行为与历史用户或实体活动进行比较来突出异常 (例如 UEBA 工具、SIEM 日志、行为分析)。
应用程序和 API 上下文：来自 WAF、API 网关或可观察性平台的元数据，用于识别异常或滥用模式 (例如 WAF 日志、API 网关遥测、可观察性数据)。
风险评分：根据实时关联和攻击上下文分配严重性或优先级 (例如 Splunk RBA, Microsoft Sentinel, Exabeam)。

CloudTrail 示例

场景：一个原始 AWS CloudTrail 事件显示有人调整了 S3 存储桶策略。根据以下几个变量，这可能值得深入调查：

存储桶中的数据类型 (敏感或非敏感？)
资源的重要性 (是否是核心资产？)
谁进行了更改 (管理员还是未授权用户？)
更改的性质 (更安全还是更不安全？)
这是否偏离了"正常"活动？(一天中的时间、MFA、用户代理等)

富化我们的示例 CloudTrail 事件后发现，它是一个未使用 MFA 认证的用户，从 Tor 出口节点连接，并显示访问关键财务记录的活动。有了这些额外的上下文，它不再只是一个随机的 S3 策略更改，而是值得调查的事件。

让我们看看如何富化这个事件。

处理前

原始 CloudTrail 日志提供了发生了什么、在哪里、行为者和其他元数据的快照，但没有上下文，它们很难大规模解释。许多现代企业环境每天会看到数百万个 CloudTrail 事件。

以下是未处理的 CloudTrail 事件示例：

{"eventVersion": "1.09","userIdentity": {"type": "IAMUser","principalId": "AIDA4EAEXAMPLE","arn": "arn:aws:iam::123456789012:user/david.miller","accountId": "123456789012","accessKeyId": "AKIA4EAEXAMPLEKEY","userName": "david.miller","sessionContext": {"attributes": {"creationDate": "2025-02-12T02:15:00Z","mfaAuthenticated": "false"           }       }   },"eventTime": "2025-02-12T02:17:32Z","eventSource": "s3.amazonaws.com","eventName": "PutBucketPolicy","awsRegion": "us-east-1","sourceIPAddress": "45.92.157.198","userAgent": "aws-cli/2.15.0 Python/3.9.7","requestParameters": {"bucketName": "financial-records","Policy": "{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"*"},"Action":["s3:GetObject"],"Resource":"arn:aws:s3:::financial-records/*"}]}"   },"responseElements": "null","requestID": "9d478fc1-4f10-490f-a26b-0e9327d54c5a","eventID": "eae87c48-d421-4626-94f5-1ac994d3e932","readOnly": false,"eventType": "AwsApiCall","managementEvent": true,"recipientAccountId": "123456789012","eventCategory": "Management","tlsDetails": {"tlsVersion": "TLSv1.2","cipherSuite": "ECDHE-RSA-AES128-GCM-SHA256","clientProvidedHostHeader": "s3.amazonaws.com"   },"sessionCredentialFromConsole": "false"}

乍一看，这个日志告诉我们 IAM 用户 David Miller 对 S3 存储桶执行了操作，但对肉眼来说，它缺乏关于他具体做了什么以及可能带来什么影响的上下文。

实际上，David Miller 修改了 S3 存储桶 (financial-records) 的策略以允许公共访问，意味着现在互联网上的任何人都可以读取存储桶中的文件。这是在没有使用 MFA 的情况下完成的。

处理后

通过富化日志记录，我们可以将这个基本日志转变为一个高上下文、可操作的事件，帮助描绘用户操作的更全面图景。正如你将看到的，富化后的记录向用户清晰表明这个事件很可能是恶意活动：

{"timestamp": "2025-02-12T02:17:32Z","account_context": {"account_id": "123456789012","account_name": "prod-finance" },"actor": {"user": "david.miller","user_type": "IAMUser","authentication_context": {"mfa_status": "NOT_USED","mfa_required": true   } },"action": {"event_name": "PutBucketPolicy","classification": "CRITICAL","impact": "PUBLIC_DATA_EXPOSURE","policy_analysis": {"changes": ["granted_public_access","removed_encryption"     ],"affected_permissions": ["s3:GetObject"],"public_access": true   } },"resource_context": {"resource_type": "S3 Bucket","resource_name": "financial-records","Resource_arn": "arn:aws:s3:::financial-records","region": "us-east-1","tags": {"contains-pii": "true","compliance-scope": "pci-dss,sox","department": "finance"   } },"source_context": {"ip": "45.92.157.198","geo_location": { "country": "Russia", "city": "Moscow" },"network_context": {"tor_exit_node": true   },"threat_intel": {"known_malicious": true,"active_c2_node": true   } }}

提示：此处显示的富化 CloudTrail 事件是一个代表性示例。实际结构和字段将根据你环境中使用的富化来源、工具和管道而有所不同。这旨在说明富化上下文可能的样子——而不是一个标准格式。

富化后的事件从威胁情报源、GeoIP 数据库、资产清单和 AWS IAM 收集上下文。如果没有富化，分析师为了收集这么多上下文，他们需要运行冗长、耗时的关联查询并在多个工具之间跳转。这可能需要每个事件花费 20-60 分钟，甚至更多。最令人沮丧的是，这些手动搜索往往导致死胡同 (又称误报)，这是成为安全运营人员最困难的部分之一。

通过利用自动化富化，安全团队可以重获那些时间和精力，专注于更高优先级的任务，如构建调查手册或更好的检测机制。

如何应用数据富化？

现在我们已经展示了富化的价值以及它如何使原始日志记录上下文化，重要的是要退一步看看更广泛的情况：富化是如何以及何时应用的。

富化不限于单一阶段。它可以 (而且通常) 在调查或自动检测流程的多个点发生。无论在哪里或如何进行，目标始终相同：提供额外的上下文或信息，以便做出更明智的决策。

有几个因素使大规模富化变得复杂：

获取额外信息的难度 – 某些数据可能在安全工具中不易获得或无法通过 API 检索，因此需要 CSV 文件和查找函数。
缺乏共同标识符 – 来自不同来源的日志可能没有用于关联的共同标准化字段，这就是为什么数据转换至关重要。
数据量 – 某些环境每天生成数百万个日志事件。
时间和精力 – 分析师的手动富化无法与大规模数据量相匹配。

毫不奇怪，在小规模看起来简单的问题在现代企业环境的规模上变得不可能解决。

在安全运营中，时间和精力是最稀缺的资源。团队必须在投入这些资源的地方做出取舍，以最大化影响并阻止威胁。

手动富化根本无法扩展，所以下一个问题是：我们如何有效地富化事件？以及在给定工作流的哪个阶段进行？

传统上，富化发生在分析师审查事件之后：

事件发生。
有人对其进行调查。
分析师手动查询其他系统以获取额外上下文。
一旦他们觉得有足够的信息，就做出决定。

在大规模环境中，这种方法失败了——因此需要在安全工作流的不同阶段进行自动化富化。

在下一节中，我们将探讨如何、何时 (用例) 和在哪里 (阶段) 进行富化。

方法和使用案例

方法	工作原理	应用场景示例	工具
SOAR（安全编排、自动化与响应）	通过查询外部数据源的工作流自动富化信息，然后再升级告警。	当检测到可疑账户活动时，自动检查用户访问权限和最近的登录历史。	TinesPalo Alto XSOAR
SIEM 中的数据表连接	在 SIEM 查询中关联多个数据源以富化事件上下文。	将 AWS CloudTrail 日志与HR数据库连接，标记已离职员工的访问尝试。	SplunkMicrosoft Sentinel
查表	使用预加载的情报或资产清单在日志接收时进行富化。	将已知恶意 IP 列表预加载到 SIEM 中，实时标记任何匹配项。	Splunk LookupsCSV 文件
基于 API 的富化化（数据流处理）	在实时数据流中调用外部 API，在事件流经管道时进行富化。	防火墙日志在流经管道时通过 MaxMind 获取地理位置数据进行富化。	CMDBGreyNoise API
通过日志管道的接收时处理	在日志存储前应用富化化，减少查询时的开销。	DNS 日志在接收时被标记域名信誉评分。	Cribl StreamApache NiFi
后处理与威胁关联	运行计划任务，检测经过富化的数据在一段时间内的模式。	识别从可疑 IP 访问关键资产的用户，观察其长期行为。	Splunk Correlation SearchesSentinel KQL Jobs
专用富化工具	与安全平台集成的专用工具，用于按需富化数据。	工单系统自动用资产所有权数据富化事件。	Recorded FutureThreatConnect

富化不是一刀切的过程。它发生在管道的不同阶段，并根据用例服务于不同的目标。无论你是在收集点富化日志，在传输中调用 API，还是在事后关联事件，每种方法在速度、成本和上下文方面都有权衡。

一些团队依靠查找表来识别已知的恶意 IP。其他团队直接在管道中嵌入富化逻辑，使用 Cribl 或 NiFi 等工具。更先进的团队可能会从威胁情报 API 流式传输实时上下文，或使用 SOAR 手册在摄入后自动进行关联，特别是对于重要的告警。AI 安全运营工具也已经成为很好的潜在富化工具，最终目标是自动化分类。

然后还有后处理，其中计划查询随着时间的推移将信号拼接在一起，以显示慢燃威胁或通过显示在孤立事件中不明显的模式来支持威胁狩猎。

如你所见，有很多方法可以富化数据。了解每种富化方法背后的"如何"有助于你为工作选择合适的方法。它还可以帮助你避免过载 SIEM，延迟告警，或在重要时刻错过关键上下文。