Indicator-of-Compromise (IOC) Matching

* **Schema-agnostic IOC matching scan**: During an incident response (IR) engagement, an analyst or incident responder might want to perform an ad hoc scan of all the data (logs, telemetry, etc.) in a security lakehouse for a given list of atomic Indicators-of-Compromise (IOCs) without the need to have deep understanding of the table schemas. The `02_ioc_matching` notebook addresses this use case.

* **Continuous IOC matching**: The approach in the `02_ioc_matching` notebook can be easily adapted to perform incremental or continuous IOC matching using [Delta Live Tables (DLT)](https://docs.databricks.com/data-engineering/delta-live-tables/index.html). An example is given in the `03_dlt_ioc_matching` notebook.

* **Ad hoc historical IOC search**: Historical IOC search at interactive speeds can be done using summary tables constructed using DLT. An example is given in the `04_dlt_summary_table` notebook. The `06_verify_dlt` notebook provides a series of steps to verify the DLT capabilities.

* **Multi-cloud/region federated query**: Log ingestion and IOC matching can happen in each cloud or region without incurring egress costs. Hunting and triage of IOC hits can use federated queries from a single workspace to get results back from the workspaces in each cloud or region. The `07_multicloud` notebook demonstrates the use of multi-cloud and multi-region federated queries.

* **Fully-automated continuous IOC matching with continuous IOC updates**: The streaming IOC matching approach in the `03_dlt_ioc_matching` notebook and the summary table approach in the `04_dlt_summary_table` notebook can be combined and extended to fully automate the IOC matching process even when the curated set of IOCs are constantly updated. In particular, when a new IOC is added, not only should newly ingested log data be matched against the new IOC, but the historical data needs to be matched against the new IOC. The `08_handling_ioc_updates` notebook demonstrates these concepts.

Click on the "Get instant access" button in the top right corner to clone the solution accelerator repo into your workspace. Once the repo is cloned into your workspace, please execute the **RUNME** notebook in the repo in order to create the cluster and job you can use to run the notebooks.

* **不依赖Schema的IOC匹配扫描**：在事件响应（Incident Response，IR）工作中，分析师或事件响应人员可能需要针对给定的原子性入侵指标（Indicators-of-Compromise，IOC）列表，对安全湖仓中的所有数据（日志、遥测数据等）执行即席扫描，而无需深入了解表的Schema结构。`02_ioc_matching` 笔记本可用于解决该用例。
* **持续IOC匹配**：`02_ioc_matching` 笔记本中的方法可轻松适配，借助[Delta Live Tables (DLT)](https://docs.databricks.com/data-engineering/delta-live-tables/index.html) 实现增量式或持续性IOC匹配，相关示例可参考`03_dlt_ioc_matching` 笔记本。
* **即席历史IOC检索**：借助DLT构建的汇总表，可实现交互式响应速度的历史IOC检索，相关示例可参考`04_dlt_summary_table` 笔记本。`06_verify_dlt` 笔记本提供了一系列用于验证DLT功能的步骤。
* **多云/多区域联合查询**：日志摄入与IOC匹配可在各云环境或区域中完成，且不会产生出站流量成本。针对IOC命中结果的威胁狩猎与分流处置，可通过单个工作区发起联合查询，从各云环境或区域的工作区获取结果。`07_multicloud` 笔记本演示了多云与多区域联合查询的使用方法。
* **支持持续IOC更新的全自动化持续IOC匹配**：可将`03_dlt_ioc_matching` 笔记本中的流式IOC匹配方法与`04_dlt_summary_table` 笔记本中的汇总表方法相结合并扩展，即便经整理的IOC集合持续更新，也可实现IOC匹配流程的全自动化。具体而言，当新增IOC时，不仅需要将新摄入的日志数据与新IOC进行匹配，还需对历史数据执行该新IOC的匹配操作。`08_handling_ioc_updates` 笔记本演示了上述相关概念。

点击右上角的“Get instant access”按钮，将该解决方案加速器仓库克隆至你的工作区。将仓库克隆至工作区后，请执行仓库中的**RUNME**笔记本，以创建可用于运行各笔记本的集群与作业。