🛡️ SENTINEL

AI 驱动的网络防御情报平台
一个多 Agent pipeline，将原始安全日志转化为可供分析师直接使用的威胁情报。

## 面临的问题 安全团队常常在海量日志中疲于奔命。一个中等规模的组织每天会在防火墙、入侵检测系统、端点和身份验证服务中产生数百万个事件。其中绝大部分都是无用信息。而真正有价值的信号——那些表明发生了实际入侵的少数关联事件——则被淹没在其中。 传统的 SIEM 工具仅应用静态规则并发出告警，而非真正理解。分析师仍然需要阅读这些告警，跨数据源将它们关联起来，评估严重程度，并撰写事件报告。 ## SENTINEL 的功能 SENTINEL 在标准化日志上运行 LangGraph Agent pipeline。每个 Agent 负责分析师工作流的其中一个阶段，并将结构化的 state 向前传递。最终输出是一份书面的情报报告，包含关联发现、风险评分和修复指导。 **具体案例。** 假设有一份 SSH 认证日志，记录了来自同一外部 IP 的多次登录失败，随后有一次登录成功并伴随 `sudo` 提权，SENTINEL 会检测到这种暴力破解模式，将其与随后的成功登录关联为同一个安全事件，将其评级为“严重”，并在报告中明确指出攻击 IP 和遭到入侵的账户。 ## Pipeline ``` ingest ──> detect ──> correlate ──> report ``` | 阶段 | 类型 | 职责 | |---|---|---| | **Ingest** | 确定性 | 将原始日志解析为标准化的事件 schema | | **Detect** | LLM agent | 标记标准化事件中的可疑模式 | | **Correlate** | LLM agent | 将检测到的结果分组成已评分的安全事件 | | **Report** | LLM agent | 撰写面向分析师的情报报告 | Ingest 阶段特意设计为不进行 LLM 调用。日志解析是一个已经解决的问题，且在这种场景下，确定性比灵活性更有价值——这不仅能降低 token 成本，还能防止模型凭空捏造日志中根本不存在的字段。 State 会不断向前传递，因此每个 Agent 都是基于其前置阶段的处理结果进行工作，而不是重新读取原始输入。 ## 支持的日志源 | 来源 | 状态 | 格式 | |---|---|---| | 身份验证 | ✅ 已支持 | Linux `auth.log` / sshd syslog | | 防火墙 | ✅ 已支持 | 带有时间戳的动作/协议/端点记录 | | IDS/IPS | 🔜 计划中 | — | | 端点遥测 | 🔜 计划中 | — | ## 快速开始 ### 前置条件 - Python 3.10+ - 一个 Groq API key — 可在 [console.groq.com](https://console.groq.com) 免费获取 ### 安装说明 ``` git clone https://github.com/Humaira-Muqades/sentinel-cyber-intelligence.git cd sentinel-cyber-intelligence python -m venv venv source venv/bin/activate # Windows: venv\Scripts\activate pip install -r requirements.txt ``` ### 配置 ``` cp .env.example .env ``` 然后将你的密钥添加到 `.env` 中： ``` GROQ_API_KEY=your_key_here MODEL_NAME=llama-3.3-70b-versatile ``` ### 运行 ``` streamlit run app.py ``` 访问 `http://localhost:8501` 打开界面。默认情况下系统会加载示例日志，因此你可以直接运行分析，无需提供自己的数据。 ### 测试 ``` python -m pytest tests/ -v ``` ## 项目结构 ``` sentinel-cyber-intelligence/ ├── app.py # Streamlit interface ├── requirements.txt ├── .env.example │ ├── src/ │ ├── state.py # Shared state schema │ ├── parsers.py # Deterministic log parsing │ ├── llm.py # Groq client wrapper │ ├── graph.py # LangGraph StateGraph │ └── agents/ │ ├── detection.py │ ├── correlation.py │ └── reporting.py │ ├── data/samples/ # Sample logs for demo runs ├── docs/diagrams/ # Architecture diagrams └── tests/ ``` ## 设计说明 **为什么将检测与关联分开。** 一次登录失败只是噪音。四十次失败后紧接一次成功则是一个安全事件。将这两个阶段分开意味着检测 Agent 可以在标记可疑行为时保持宽松的标准，而不会产生大量告警，因为关联阶段会将相关的发现合并为一个已评分的事件。 **故障处理。** 每个 Agent 都会捕获自身的异常，并写入到一个共享的 `errors` 列表中，而不是直接抛出异常。单个阶段的失败只会降低输出质量，而不会中断整个运行过程——报告仍然会被生成，只是可用的信息会减少。 **Token 预算。** 检测阶段每次运行最多限制输入 200 个事件。超过这个数量，prompt 的成本增长速度将远超其带来的边际收益。 ## 路线图 完整的设计规划了一个包含七个 Agent 的 pipeline。v1 版本实现了其中最重要的三个。 - [ ] **Enrichment agent** — IP 信誉、资产关键性、用户角色上下文 - [ ] **Risk scoring agent** — 将评分功能从关联阶段中拆分，作为独立阶段 - [ ] **Remediation agent** — 专门的缓解措施规划 - [ ] IDS/IPS 和端点日志解析器 - [ ] MITRE ATT&CK 技术映射 - [ ] 跨运行的持久化事件历史记录 - [ ] 针对海量日志的批处理 ## 作者 **Brainlyt Labs** — 迈向智慧未来的 AI 解决方案 [LinkedIn](https://(https://www.linkedin.com/company/brainlyt-labs)/) · [GitHub](https://github.com/brainlytlabs)) · brainlylabs@gmail.com

标签：Kubernetes, 红队行动, 逆向工具