Dermot10/secops-decision-engine

# 安全运营决策引擎 # 背景 一个轻量级的安全运营中心工作流，目前主要聚焦于告警分诊决策、检测即代码以及威胁情报的利用。 作为一名AI工程师，我也在寻找可靠的用例来将AI集成到现有实践中，以发现可以通过技术增强的具体痛点。 # 技术决策 Python负责处理任何涉及AI API、数据丰富化或转换逻辑的部分。 Go负责处理任何需要在边界层实现快速、并发和可靠的功能（数据摄入、队列管理、重试、审计日志写入）。 通过消息队列进行异步通信以解耦各个实体。 关键组件- **威胁情报丰富化服务（Python）** - 集成第三方威胁情报API（VirusTotal、AbuseIPDB免费层），作为下游服务的可重用依赖项。使用FastAPI和Redis进行缓存，以遵守速率限制并允许资源管理。跨源实施置信度评分。 **告警分诊管道服务（Go + Python）** - Go服务负责数据摄入和队列管理，读取模拟告警流，处理重试，并将任务路由到worker。Python worker调用丰富化服务并调用LLM进行分类和摘要，应用置信度阈值并写入具有完整可解释性的决策。审计日志保存在此处。*关键组件* **检测即代码框架（Python）** - YAML定义的检测规则针对日志样本运行，并将告警输入管道。Git版本控制，可针对样本数据集进行测试（可能是AI工作流，但设计更严格），并跟踪误报。这是安全团队可以交互的层。- 积累检测历史，例如「是否触发？」、分诊是「自动决策」还是「升级」、是否需要「人工覆盖」，这将用于跟踪检测规则的整个生命周期。- rule_id -> [结果] 映射，允许推导每个规则的误报。- 允许隔离测试，无需基础设施依赖。 **Mini SIEM 被故意省略**。系统将获得刚好足够的日志摄入来供给管道，仅此而已。一个轻量级的Go服务，用于tail文件或从socket读取。不会是完整的SIEM，因此不可查询，主要只是脚手架。 # 设计决策 我选择不过多关注这个分布式构建的SIEM平台方面，至少主要是为了确保我满足最佳时间限制，并更深入地研究SOC工作流中代表性不足的方面。 # 构建决策 顶级 docker compose.yml 将系统绑定在一起作为一个系统。 根compose将处理外部依赖（redis、rabbitMQ、数据库（目前是轻量级））。

标签：AI, AMSI绕过, API集成, AV绕过, C2, DLL 劫持, Enrichment, FastAPI, Git版本控制, Go, LLM, LSASS转储, Python, Redis, Ruby工具, SOAR, SOC自动化, Unmanaged PE, YAML, 假阳性跟踪, 决策引擎, 可观测性, 大语言模型, 威胁情报, 威胁检测, 安全库, 安全运营中心, 审计日志, 工作流自动化, 开发者工具, 异步处理, 搜索引擎查询, 数据丰富化, 无后门, 日志审计, 检测即代码, 检测规则, 消息队列, 缓存, 网络映射, 网络资产发现, 置信度评分, 自动化代码审查, 自动化响应, 警报分类, 请求拦截, 逆向工具, 重试机制, 队列管理