katerina20/cloud-threat-anomaly-lab

GitHub: katerina20/cloud-threat-anomaly-lab

CTAL 是一个基于合成数据的可解释云安全异常检测研究实验室,提供规则引擎、统计检测和 Isolation Forest 三种检测器及可复现的基准测试框架。

Stars: 28 | Forks: 9

# Cloud Threat Anomaly Lab (CTAL) **一个用于可解释云威胁检测和可复现基准测试的隐私安全基础。** CTAL 定义了一个稳定的云安全事件 schema,生成包含正常行为和标记攻击场景的确定性合成数据集,使用三个互补的透明检测器对这些事件进行评分,并进行可复现的基准测试。它有意**不**使用雇主、客户或生产数据。 ## 发布状态 **版本 0.1.0 — 初始研究和演示发布。** CTAL 是一个开源实验室,用于对合成数据进行可解释的云安全异常检测。它**不是**一个完整的 SIEM,**未达到**生产可用状态,并且**尚未**在真实的企业环境中得到验证。在提及性能时,它始终是指在指定的阈值和检测器下针对某一合成数据集的结果;请参阅[基准测试局限性](#current-limitations)。 - 发布说明:[docs/releases/v0.1.0.md](docs/releases/v0.1.0.md) - 更新日志:[CHANGELOG.md](CHANGELOG.md) - 可复现性:[docs/reproducibility.md](docs/reproducibility.md) ## 当前范围 ### v0.1 基础 - 规范的 JSONL 事件 schema - 确定性合成数据生成器 - 正常用户和服务账户活动 - 六个标记的云安全场景 - 用于未来时间线关联的事件 ID - 内置验证 - 单元测试 - GitHub Actions CI - 即用型演示数据集 ### v0.2 可解释的基于规则的检测 - 每个执行者的连续行为基线 - 十二条透明的加权规则 - 风险评分 (0–100)、严重程度、匹配规则以及通俗易懂的解释 - JSONL 告警输出和 JSON 总结报告 - `ctal detect` CLI 命令 - 仅使用标准库,无 ML,无外部服务 ### v0.3 统计检测与基准测试 - 稳健的统计行为检测器(对数空间中的中位数/MAD) - 具有有限历史记录的分层数值基线 - 带有解释和机器可读上下文的两个统计信号 - 通过 `ctal detect --detector` 选择检测器 - 事件、incident 和场景级别的评估 - 带有 JSON 和 Markdown 报告的 `ctal benchmark` CLI 命令 - 仍然仅使用标准库,依然不使用机器学习 ### v0.4 基线更新策略与消融实验 - 可配置的统计基线更新策略 (`always`, `risk-gated`) - 每个结果的基线更新诊断和运行级别的更新计数器 - `ctal detect --baseline-policy` 和 `--baseline-gate-threshold` - `ctal ablation` CLI 命令,用于比较带有 JSON 和 Markdown 报告的策略 - 每个场景的评分轨迹和污染指标 - 默认行为保持不变:在没有新标志的情况下,检测功能与以前完全一样 ### v0.5 Isolation Forest 与冻结留出推理 - 可选的 ML 扩展(`pip install 'cloud-threat-anomaly-lab[ml]'`,仅限 scikit-learn) - 结构上无标签和无标识符的 ML 特征契约 - `ctal generate --normal-only` 用于已知干净的合成训练基线 - `ctal train` 生成带有 JSON 元数据的带版本控制和哈希值的模型包 - `ctal detect --detector isolation-forest --model ...` 冻结留出推理 - 经验百分位校准到现有的 0-100 风险评分量表 - 情境观察,明确指出并非精确的模型归因 - `ctal ml-benchmark` 在相同的评估数据集上比较四种方法 - 规则和统计检测保持不变且无需依赖 ### v0.6 本地调查仪表板 - 可选的 UI 扩展(`pip install 'cloud-threat-anomaly-lab[ui]'`,Streamlit + Plotly) - 带有演示和分析模式的 `ctal dashboard` 启动器 - 通过现有的 SecurityEvent schema 在内存中验证上传的 JSONL - 规则、统计(两种基线策略)以及受信任模型的 Isolation Forest 分析 - 概览指标、可过滤的告警表、告警详情和活动时间线 - 已提交的四方法基准测试和基线消融可视化 - 在内存中生成 JSONL、CSV 和 JSON 导出 - 隐私优先的消息传递和受信任模型工件处理 - 一个本地分析和演示工具——特意设计为不是 SIEM ## 包含的场景 1. 来自新区域和未见 IP 的登录 2. 重复的身份验证失败后成功 3. 权限提升 4. 意外的生产环境密钥访问 5. 异常的批量数据下载 6. 特权 Kubernetes pod 执行 ## 安装 CTAL 要求 Python 3.11+。核心部分仅依赖标准库;可选的检测器和仪表板位于扩展功能中。 | 安装 | 命令 | 添加 | 启用 | |---------|---------|------|---------| | 核心版 | `pip install cloud-threat-anomaly-lab` | — | generate, rule + statistical detect, benchmark, ablation | | ML 版 | `pip install "cloud-threat-anomaly-lab[ml]"` | scikit-learn | train, Isolation Forest detect, ml-benchmark | | UI 版 | `pip install "cloud-threat-anomaly-lab[ui]"` | streamlit, plotly | `ctal dashboard` | | 组合版 | `pip install "cloud-threat-anomaly-lab[ml,ui]"` | 以上所有 | trusted-model dashboard analysis | 从源代码检出版本中,将包名替换为 `-e .`(例如 `pip install -e ".[ml,ui,dev]"`)。核心导入绝不要求 scikit-learn、streamlit、 plotly、numpy 或 joblib——这些库仅在使用其功能时才会延迟加载。 ## 快速开始 ``` python -m venv .venv source .venv/bin/activate # Windows: .venv\Scripts\activate pip install -e . ctal --version ctal generate --users 25 --days 7 --seed 42 --out datasets/local-demo.jsonl ctal detect --input datasets/local-demo.jsonl --out reports/local-alerts.jsonl --summary reports/local-summary.json ``` 或者在不安装包的情况下: ``` PYTHONPATH=src python -m ctal generate --users 25 --days 7 --seed 42 --out datasets/local-demo.jsonl ``` 运行测试: ``` PYTHONPATH=src python -m unittest discover -s tests -v ``` ## 检测 `ctal detect` 使用基于规则的引擎对每个事件进行评分,将告警写入 JSONL, 并写入总结报告: ``` ctal detect \ --input datasets/demo.jsonl \ --out reports/demo-alerts.jsonl \ --summary reports/demo-detection-summary.json \ --threshold 25 ``` | 参数 | 描述 | |----------|-------------| | `--input` | 必需。`SecurityEvent` 记录的 JSONL 文件。 | | `--out` | 告警 JSONL 输出路径。默认为 `reports/alerts.jsonl`。 | | `--summary` | 总结 JSON 输出路径。默认为 `reports/detection-summary.json`。 | | `--threshold` | 报告为告警的最低风险评分,0–100。默认为 `25`。 | 每个事件都会获得一个 0 到 100 的风险评分,该评分是通过累加其匹配规则的权重并将 总数限制在 100 来构建的。严重程度直接由评分决定: | 评分 | 严重程度 | |-------|----------| | 0–24 | `low` | | 25–49 | `medium` | | 50–74 | `high` | | 75–100 | `critical` | 默认阈值 25 会报告 `medium` 及以上级别的风险。 ### 告警示例 ``` { "event_id": "evt-...", "timestamp": "2026-01-06T04:20:00+00:00", "actor_id": "service-account-004", "incident_id": "inc-...", "risk_score": 85, "severity": "critical", "matched_rules": [ "new_source_ip", "new_source_region", "privileged_kubernetes_execution", "first_time_sensitive_resource_access" ], "reasons": [ "Source IP 203.0.113.199 has not previously been observed for this actor.", "Source region eu-west has not previously been observed for this actor.", "Interactive Kubernetes execution on production workload cluster/prod/pod/payments.", "First observed access by this actor to critical-sensitivity production resource cluster/prod/pod/payments." ], "action": "kubernetes.pod.exec", "environment": "production", "resource_id": "cluster/prod/pod/payments", "source_ip": "203.0.113.199", "source_region": "eu-west" } ``` ### 事件排序 **CTAL 按时间戳处理事件,并在时间戳完全相等时保留原始输入顺序。任意事件标识符不 决定行为基线顺序。** 一个共享工具 (`stable_chronological_order`) 为每个检测器、ML 训 练、评估和仪表板实现了此契约,因此更改 UUID 值绝不会改变任何评分、基线、新颖性特征 或结果顺序。 对于时间戳完全相等的情况,源行顺序被视为可用的排序信号。 更改源行顺序可能会影响连续行为分析——这是一个既定属性,而不是意外:同一时刻的两个 事件没有其他可靠的排序证据。 ### 连续基线 引擎按时间顺序处理事件,并为每个执行者维护一个先前所见 IP、区域、动作、资源、 资源类型、环境、动作/资源对以及活动时间的基线。 每个事件都是**在该事件发生之前**根据基线进行评分,然后才将其并入基线。没有任何未来 事件可以影响较早的评分,这使得结果保持可靠且可复现。 由于执行者的最初几个事件没有可比较的内容,依赖于基线的规则(`new_source_ip`、 `new_source_region`、`unusual_activity_hour`、 `first_time_sensitive_resource_access`)会保持沉默,直到执行者至少拥有 `MIN_BASELINE_EVENTS = 3` 个先前事件。如权限提升等直接的高风险规则仍会立即触发。 ### 真实标签被排除在检测之外 **合成标签 `is_anomaly`、`scenario` 和 `incident_id` 绝不会被用作检测器特征。** 它们 不参与任何风险评分、严重程度、匹配规则或解释。 这是在结构上强制执行的,而不是依靠约定:规则永远看不到 `SecurityEvent`。它们接收到的是一 个根本不包含这些字段的 `EventFeatures` 投影,因此规则无法读取它们。`incident_id` 仅在 事后作为上下文元数据复制到结果中以供关联。这些标签纯粹是为了评估和报告而存在,并且有一个 测试断言,仅在上述三个字段上有所不同的两个事件会产生完全相同的评分、 严重程度、规则列表和解释。 完整的规则和权重参考:[docs/detection-methodology.md](docs/detection-methodology.md)。 ## 统计检测 统计检测器回答了一个与规则不同的问题:**对于该执行者自身的历史记录而言,此事件的 数值活动是否异常巨大?** ``` ctal detect \ --detector statistical \ --input datasets/demo.jsonl \ --out reports/demo-statistical-alerts.jsonl \ --summary reports/demo-statistical-summary.json \ --threshold 25 ``` `--detector` 接受 `rule`(默认值)或 `statistical`。省略它将使原始的基于规则的行为与 之前完全保持一致。 它**不是**机器学习。没有模型,也没有训练阶段——它使用固定的、公开阈值的稳健描述性 统计。对于每个事件,它使用 `log1p` 空间中的中位数和绝对中位差,将 `request_count_5m` 和 `bytes_transferred` 与执行者先前的值进行比较,并且仅对上尾部分进行评分: | 稳健 z 分数 | 权重 | |----------|--------| | >= 3.5 且 < 5.0 | +20 | | >= 5.0 且 < 8.0 | +30 | | >= 8.0 | +40 | 基线是从具有至少 8 个先前观察值的最具体范围内选择的—— `actor + action`,然后是 `actor + resource_type`,接着是 `actor`——并且绝不回退到其他 执行者的历史记录。历史记录不足时不产生信号,而不是产生告警。 统计告警原因示例: ``` Data transfer volume is a statistical outlier: 1.50 GB versus a historical median of 3.43 MB; robust z-score 11.15 using 8 prior actor/resource-type observations. ``` 完整方法参考: [docs/statistical-detection-methodology.md](docs/statistical-detection-methodology.md)。 ### 基线污染 统计检测器是一个在线学习器:每个事件都根据执行者先前的历史记录进行评分,然后并入其中。 当每个事件都进入基线时——包括发出告警的事件——攻击者自身的活动会扩大其基线,因此随后的 每个攻击事件看起来比前一个*更不*异常。在捆绑的演示中,四个 `bulk_data_download` 事件 从 1.50 GB 升级到 2.25 GB,而它们的评分却在下降(70、70、50、50)。这种评分衰减是 可测量的,并且被记录下来而不是被隐藏。 ### 基线更新策略 `ctal detect --detector statistical` 接受一个基线更新策略: - **`always`**(默认):每个评分事件都会更新基线。这完整地保留了原始行为并 保持现有运行的可复现性。 - **`risk-gated`**(实验性):首先对每个事件进行评分;如果其统计风险评分低于 基线门控阈值,它会更新基线,否则将完全保留。门控仅使用检测器对当前事件自身的评分—— 绝不是真实标签,绝不是基于规则的信号,也绝不是未来事件。 ``` ctal detect \ --detector statistical \ --baseline-policy risk-gated \ --baseline-gate-threshold 25 \ --input datasets/demo.jsonl \ --out reports/demo-statistical-risk-gated-alerts.jsonl \ --summary reports/demo-statistical-risk-gated-summary.json \ --threshold 25 ``` **告警阈值和基线门控阈值是不同的决策。** `--threshold` 控制哪些结果作为告警写入;`--baseline-gate-threshold` 控制事件的指标是否 更新统计历史记录。它们共享默认值 25,但可以独立设置。门控阈值接受 0–100:门控为 0 会 保留每个事件,门控为 100 仅保留评分为 100 的事件。冷启动事件评分为 0,因此只要门控值大于 0,它就会更新基线。 门控是事件级别的,而不是针对每个指标的:保留可疑事件也会排除其正常的指标观察结果。 风险门控并未作为最佳策略提出——受门控的基线可能会变得陈旧,始终保持在门控值之下的 攻击者仍然可以重塑它。每个统计结果都会记录 `baseline_updated` 和一个通俗的英文说明 `baseline_update_reason`,并且每个统计摘要都会报告有多少更新被应用和跳过。 ### 基于规则 vs 计 vs Isolation Forest 这三种检测器在设计上是互补的,而不是相互竞争的实现: | | 基于规则 | 统计 | Isolation Forest | |---|---|---|---| | 询问的问题 | 这是否匹配已知的恶意模式? | 这对于此执行者来说不寻常吗? | 与单独的训练基线相比,这是一个全局行为异常值吗? | | 输入 | 分类数据:IP、区域、动作、敏感度、环境 | 数值:请求速率、传输量 | 混合向量:容量、小时、类别、相对于执行者的新颖性标志 | | 需要的历史记录 | 3 个先前事件(仅限分类规则) | 8 个先前观察结果 | 单独的训练数据集(每个拟合的执行者行需 3 个先前事件) | | 学习方式 | 无 | 无(描述性统计) | 无监督,训练一次,推理时冻结 | | 捕获 | 已知的攻击形态,即使在第一个事件上 | 没有为它们编写规则的容量异常 | 任何规则都无法预见的异常组合 | | 遗漏 | 任何没有规则的攻击 | 在两个指标上都不活跃的攻击 | 类似于训练基线的事件;在分布偏移下会牺牲精确率 | ## 基准测试 `ctal benchmark` 在相同的阈值下对相同的事件运行每个检测器,并写入 JSON 和 Markdown 报告: ``` ctal benchmark \ --input datasets/demo.jsonl \ --out reports/demo-benchmark.json \ --markdown reports/demo-benchmark.md \ --threshold 25 ``` 它在三个层级上进行评估:**事件**(完整的混淆矩阵、精确率、召回率、F1、 假阳性率、特异性、准确度)、**incident**(当 incident 的任何事件触发告警时,即视为该 incident 被检测到)和**场景**(每个场景的检测和首次告警时间)。 在捆绑的演示数据集上,两个检测器具有明显不同的特征——规则检测器发现了更多并 产生了假阳性;统计检测器发现得更少且未产生假阳性。两者都不是“更好的”;你想要哪种 权衡取决于此基准测试无法模拟的运行上下文。请参阅 [reports/demo-benchmark.md](reports/demo-benchmark.md)。 ## Isolation Forest 检测(可选 ML) 第三种检测器是无监督的 Isolation Forest,作为可选依赖项保留,以便 CTAL 的其余部分 仅依赖标准库: ``` pip install -e ".[ml]" # adds scikit-learn ``` 在没有扩展的情况下请求 ML 功能会产生清晰的安装提示;不会 影响其他命令。 ### 1. 生成仅包含正常情况的训练基线 ``` ctal generate \ --users 40 \ --days 14 \ --seed 31415 \ --normal-only \ --out datasets/demo-ml-training.jsonl ``` `--normal-only` 不注入攻击场景:每个事件都被标记为正常,没有 incident ID,而普通的失败和拒绝活动仍然会发生。这为演示创建了一个 **已知干净的合成基线**——这是真实部署所不具备的奢侈条件。真实的训练基线应该是 一段被认为足够干净的时期,并且可能包含未检测到的威胁。 ### 2. 训练模型 ``` ctal train \ --detector isolation-forest \ --input datasets/demo-ml-training.jsonl \ --model models/demo-isolation-forest.joblib \ --metadata models/demo-isolation-forest-metadata.json \ --n-estimators 200 \ --random-state 42 \ --tail-start-quantile 0.98 ``` 训练按时间顺序处理事件,忽略所有标签,从严格在先前的事件中为每个执行者构建新颖性 特征,跳过每个执行者的前 3 个冷启动行以避免拟合(它们仍然会更新特征配置),并将排序后的训练异常分数分布存储为 校准参考。该包记录了训练文件的 SHA-256、两个 schema 版本和库版本。 ### 3. 运行冻结留出推理 ``` ctal detect \ --detector isolation-forest \ --model models/demo-isolation-forest.joblib \ --input datasets/demo.jsonl \ --out reports/demo-isolation-forest-alerts.jsonl \ --summary reports/demo-isolation-forest-summary.json \ --threshold 25 ``` 推理是**冻结留出**的,而不是在线学习:评估事件永远不会更新 模型、配置文件或校准。新颖性标志仅针对训练配置文件进行计算。 ### 百分位校准 原始的 Isolation Forest 分数不是概率,并且没有固定的尺度。每个 推理分数都会被转换为它在*训练*分数分布中的经验百分位数,然后 映射到 CTAL 的 0-100 风险量表:低于尾部起始分位数(默认 0.98)的百分位数保持在 25 以下(在默认阈值下绝不发出告警), 分位数本身精确映射到 25,而百分位数 1.0 映射到 100。**其结果是根据训练基线进行的经验校准,而不是事件为恶意事件的概率。** ### 情境观察,而非归因 Isolation Forest 分数是由随机树的集合产生的,无法在此处对每个特征进行精确分解。因此,每个 ML 告警都包含一个主要原因 (“Isolation Forest 将此事件分类在经校准的异常尾部:相对于训练基线的第 99.4 百分位。”)以及最多三个确定性的**情境观察**(针对此执行者的未见 IP/区域/动作/资源,相对于训练中位数的异常大容量、存在身份验证失败、罕见的训练时间)。 这些有助于分析师审查事件;它们不能证明哪些特征驱动了 评分,也不是特征重要性或 SHAP 值。 ### 4. 留出基准测试 ``` ctal ml-benchmark \ --training-input datasets/demo-ml-training.jsonl \ --input datasets/demo.jsonl \ --out reports/demo-ml-benchmark.json \ --markdown reports/demo-ml-benchmark.md \ --threshold 25 \ --random-state 42 \ --tail-start-quantile 0.98 ``` 这会在内存中训练一个新的模型(除非给出了 `--model-out`,否则不会写入工件),并在相同的评估事件上比较四种方法:规则、统计 always、统计 risk-gated 和 Isolation Forest。 在捆绑的演示中,特征差异非常大。规则检测器发现了 12 个告警,精确率为 91.7%,并检测到了所有 6 个场景。统计检测器以完美的精确率发现了 4 次批量 下载,除此之外没有其他发现。Isolation Forest 达到了与 规则相同的事件召回率(78.6%:它捕获了批量下载、失败后成功的 爆发以及密钥访问)——但精确率为 6.6%,因为有 156 个正常事件也 落在其校准的尾部。这在很大程度上是真实的分布偏移:评估 环境的生成使用了与训练基线不同的种子和总体,因此 许多执行者合理地偏离了他们的训练配置文件。它遗漏了三个 规则能瞬间捕获的单事件分类场景(它们的百分位数刚好 低于尾部)。这两种方法都不是普遍更好的;请参阅 [reports/demo-ml-benchmark.md](reports/demo-ml-benchmark.md) 和 [docs/isolation-forest-methodology.md](docs/isolation-forest-methodology.md)。 ## 调查仪表板(可选 UI) 一个本地 Streamlit 仪表板,用于探索事件、告警、解释以及 已提交的基准测试: ``` pip install -e ".[ui]" # streamlit + plotly ctal dashboard --demo # explore the committed synthetic demo artifacts ``` 要启用实时的 Isolation Forest 分析,请将仪表板指向一个**受信任的、 服务器本地**的模型工件(浏览器永远无法上传模型): ``` pip install -e ".[ui,ml]" ctal train --detector isolation-forest \ --input datasets/demo-ml-training.jsonl \ --model models/local-isolation-forest.joblib ctal dashboard --model models/local-isolation-forest.joblib ``` **演示模式**展示了已提交的演示数据集和预计算的报告——规则、 统计(两种基线策略)和 Isolation Forest 告警、四方法 留出基准测试以及基线策略消融——无需二进制模型。 **分析模式**接受一个 JSONL 上传,在内存中针对 `SecurityEvent` schema 对其进行验证(默认限制为 25 MB,可通过 `--max-upload-mb` 配置),并 在其上运行现有的检测器。上传的文件不携带受信任的真实标签,因此 仪表板仅在此处显示操作比较(告警计数、严重程度、评分)—— 绝不会显示精确率或召回率。 **隐私:** 分析在本地 Streamlit 进程中运行;CTAL 不会自行进行外部网络调用,也 不会故意持久化上传的事件内容。切勿 上传凭证、机密、个人数据、雇主数据或客户数据。 基准测试视图重复了已提交报告的注意事项:在演示中,Isolation Forest 匹配了基于规则的*事件级别*召回率,但没有匹配 incident 或场景召回率,并且在跨总体的合成留出分布偏移下,其精确率大幅降低。没有一种方法被认为是普遍优越的。 完整指南:[docs/dashboard-guide.md](docs/dashboard-guide.md)。 ### 截图 演示模式仪表板的截图将位于 [docs/screenshots/](docs/screenshots/)(目前为占位符;只有已提交的合成 演示内容会被捕获在那里)。 ## 基线策略消融 `ctal ablation` 在相同的事件上运行两次统计检测器——每个基线更新策略运行一次,其他所有内容保持不变——并写入比较它们的 JSON 和 Markdown 报告: ``` ctal ablation \ --input datasets/demo.jsonl \ --out reports/demo-baseline-ablation.json \ --markdown reports/demo-baseline-ablation.md \ --threshold 25 \ --baseline-gate-threshold 25 ``` 报告包括每个策略的完整事件/incident/场景指标、带有稳健 z 分数的每个场景的评分轨迹,以及诊断性污染指标(首个/末尾评分、分数下降计数、跳过的更新)。 在捆绑的演示中,两种策略都产生相同的 4 个告警,没有假阳性。 区别在于轨迹:在 `always` 下,四个升级的 `bulk_data_download` 事件得分为 70、70、50、50,传输稳健 z 分数从 11.15 衰减到 6.82;在 `risk-gated` 下,四个事件全部得分为 70,稳健 z 分数从 11.15 上升到 11.90,因为攻击事件从未进入基线。这是与 always 策略下的基线污染相一致的评分衰减减少——在这个单一的合成数据集上。这不能证明风险门控在一般情况下更好。请参阅 [reports/demo-baseline-ablation.md](reports/demo-baseline-ablation.md) 和 [docs/baseline-contamination-ablation.md](docs/baseline-contamination-ablation.md)。 ### 标签仅用于评估 真实标签**仅**由 `ctal.evaluation` 读取,严格在检测完成之后。检测代码从不导入评估包——这种单向依赖使得边界可以一目了然地审计。 ## 当前局限性 这些是透明的基线,而不是生产级的 SIEM: - 规则权重和统计阈值是人工调整的安全判断,而不是 经过统计校准的风险。25 的基线门控阈值同样是 判断的默认值,而不是经验校准值。 - **在默认的 `always` 策略下,每个评分事件都会更新基线,包括 发出告警的事件。** 因此,持续的攻击者活动会污染未来的基线。 这在演示中是可以衡量的:四个 `bulk_data_download` 事件变得*更大* (从 1.50 GB 到 2.25 GB),而它们的统计评分却*下降*了(70、70、50、50),因为 攻击者自身的流量扩大了他们的基线。 - `risk-gated` 策略减轻了演示数据集上的特定衰减,但它是一个 带有自身失败模式的实验性策略:事件级别的门控也会在可疑事件上保留 正常指标,当真实行为发生变化时,受门控的基线可能会变得陈旧,并且将每一步都保持在门控以下的攻击者仍然可以向上拉动基线。仍然没有衰减、窗口化或分析师反馈机制。 - 事件是单独评分的。没有跨事件关联或 incident 级别的 聚合,因此每一步都低于阈值的慢速攻击可能会被遗漏。 - 统计检测器仅分析请求速率和传输量。 - `auth_failures_15m` 和 `request_count_5m` 被按原样信任,没有重新计算。 - 执行者仅与其自己的过去进行比较,从不与同侪群体进行比较。 - 新 IP 作为纯字符串进行比较,没有子网、ASN、地理或 VPN 感知。 - 没有 allowlist、抑制、去重或调整界面。 - Isolation Forest 风险评分是针对 合成仅含正常数据的训练基线的经验百分位校准——而不是恶意概率——并且它的 尾部起始分位数 (0.98) 是一个设计参数,而不是校准值。 - 冻结的 ML 推理不会适应合理的行为漂移,并且它的情境 观察是分析师的提示,而不是精确的模型归因。 - ML 模型工件是 pickle 兼容的;仅从受信任的来源加载工件。 - 仅在合成数据上进行基准测试。标签是生成器的意见,因此这些 数字不能说明真实世界的精确率或召回率。 ## 事件示例 ``` { "event_id": "evt-...", "timestamp": "2026-01-05T18:40:00+00:00", "actor_id": "user-004", "actor_type": "human", "source_ip": "203.0.113.41", "source_region": "eu-west", "action": "secrets.read", "resource_id": "secret/prod/database-password", "resource_type": "secret", "resource_sensitivity": "critical", "result": "success", "environment": "production", "bytes_transferred": 0, "request_count_5m": 2, "auth_failures_15m": 0, "incident_id": "inc-...", "is_anomaly": true, "scenario": "unexpected_secret_access" } ``` ## 路线图 ### v0.2 — 检测核心 - ~~基于规则的检测器~~(已交付) - ~~可解释的风险评分~~(已交付) ### v0.3 — 统计检测和基准测试 - ~~统计偏差检测器~~(已交付) - ~~精确率、召回率、F1、假阳性率~~(已交付) - ~~Incident 和场景级别的评估~~(已交付) - ~~可复现的检测器基准测试~~(已交付) ### v0.4 — 检测质量 - ~~可配置的基线更新策略(always, risk-gated)~~(已交付) - ~~带有污染指标的可复现的基线策略消融~~(已交付) ### v0.5 — 无监督 ML 检测 - ~~带有冻结留出推理的 Isolation Forest~~(已交付) - ~~仅含正常数据的训练数据生成~~(已交付) - ~~经验百分位校准和四方法留出基准测试~~(已交付) ### v0.6 — 分析师体验 - ~~本地 Streamlit 调查仪表板 (`ctal dashboard`)~~(已交付) - ~~内存中上传分析和导出~~(已交付) - 来自已提交的合成演示的仪表板截图 - 跨事件和会话关联 - 同侪群体基线 - 针对每个检测器的阈值校准(包括经验门控和尾部分位数 校准) - ML 检测训练/评估执行者总体对齐研究 ### v0.7 — 适配器和隐私 - AWS CloudTrail 适配器 - Kubernetes 审计日志适配器 - PII 掩码 - 可配置的保留策略 - MITRE ATT&CK 映射 ## 项目结构 ``` src/ctal/ ├── schema.py # SecurityEvent schema ├── generator.py # deterministic synthetic data ├── __main__.py # CLI entry point ├── detection/ # rules, statistics, baseline policies (no label access) ├── ml/ # Isolation Forest (optional ML extra) ├── evaluation/ # metrics, benchmarks, ablation (the only label reader) └── dashboard/ # Streamlit app + packaged demo assets (optional UI extra) datasets/ # committed synthetic datasets reports/ # committed reproducible reports docs/ # methodology, architecture, reproducibility, releases release/ # artifact manifest (SHA-256 of committed artifacts) scripts/ # release tooling (manifest, asset sync, validation) ``` 架构和边界:[docs/architecture.md](docs/architecture.md)。 ## 文档 - [架构](docs/architecture.md) — pipeline 和检测/评估边界 - [可复现性指南](docs/reproducibility.md) — 确切命令以及哪些内容是字节可复现的 - [发布说明 v0.1.0](docs/releases/v0.1.0.md) 和 [更新日志](CHANGELOG.md) - [发布检查表](docs/release-checklist.md) - 方法论:[规则](docs/detection-methodology.md)、 [统计](docs/statistical-detection-methodology.md)、 [Isolation Forest](docs/isolation-forest-methodology.md)、 [基线消融](docs/baseline-contamination-ablation.md) - [事件 Schema](docs/event-schema.md) · [仪表板指南](docs/dashboard-guide.md) ## 可复现性和发布工具 ``` python scripts/artifact_manifest.py # verify committed artifact SHA-256 python scripts/sync_demo_assets.py --check # packaged demo copies match canonical python scripts/validate_release.py # full release preflight ``` 有关哪些工件是字节可复现的以及如何从比较中排除时间字段的信息,请参阅 [docs/reproducibility.md](docs/reproducibility.md)。 ## 贡献 欢迎贡献。请参阅 [CONTRIBUTING.md](CONTRIBUTING.md) 和 [行为准则](CODE_OF_CONDUCT.md)。按照 [SECURITY.md](SECURITY.md) 的要求私下报告安全问题。 ## 净室开发规则 - 仅使用个人设备和账户。 - 仅使用合成或明确公开的数据。 - 请勿复制雇主或客户的代码、schema、规则、查询、截图或术语。 - 保留显示独立开发过程的设计笔记和提交历史。 - 在独立验证之前,请勿声称具备生产就绪状态或真实世界的性能。 ## 引用 如果您在研究或写作中使用 CTAL,请使用 [CITATION.cff](CITATION.cff) 中的元数据对其进行引用。 ## 许可证 Apache License 2.0。请参阅 [LICENSE](LICENSE)。
标签:AMSI绕过, Apex, Kubernetes, 合成数据, 威胁检测, 孤立森林, 异常检测, 机器学习, 逆向工具