ThisaraKawinda/security-log-dashboard

# 安全日志分析仪表板 这是一个基于 Python 的安全监控工具，用于收集、解析、分析和可视化 Windows 安全事件日志，以识别可疑活动并提供可操作的安全洞察。 该项目作为 SOC 分析师的作品集项目而构建，旨在展示真实的检测工程、日志取证和安全数据可视化技能。 ## 截图 ### 仪表板概览  ### 活动警报面板  ### 登录活动热力图  ## 项目状态 | 阶段 | 描述 | 状态 | |-------|-------------|--------| | 0 | Windows 日志基础 | 完成 | | 1 | 环境和审核策略配置 | 完成 | | 2 | 日志收集和解析引擎 | 完成 | | 3 | 检测引擎 | 完成 | | 4 | SQLite 存储层 | 完成 | | 5 | Streamlit 仪表板 | 完成 | | 6 | 报告生成 | 完成 | ## 架构 ``` Windows Security Event Log | v Log Collector (collector/) - win32evtlog EvtQuery API - Split queries: Auth vs Process events | v Event Parser (parser/) - XML normalization - Field extraction and enrichment - Event-type-specific enrichment functions | v SQLite Storage (storage/) - Indexed single-table schema - Duplicate-safe INSERT OR IGNORE - WAL mode for concurrent read/write | v Detection Engine (detection/) - Threshold, sequence, and pattern-based rules - Event and alert deduplication - Structured alert output with severity levels | v Streamlit Dashboard (dashboard/) - Interactive security visualization - Real-time metrics and alert panels - Searchable event log table - Logon activity heatmap | v Report Generator (reports/) - Automated Markdown security summaries - Executive summary with status classification - Authentication analysis and recommendations ``` ## 已实现的检测规则 | 规则 ID | 名称 | 类型 | 严重程度 | |----------|-----------------------------|-----------|----------| | BF-001 | 暴力破解检测 | Threshold | HIGH | | BF-002 | 暴力破解后成功登录 | Sequence | CRITICAL | | BF-003 | 密码喷射 | Threshold | HIGH | | ACC-001 | 创建新管理员账户 | Sequence | CRITICAL | | ACC-002 | 创建新用户账户 | Event | MEDIUM | | ACC-003 | 账户锁定 | Event | MEDIUM | | PROC-001 | 检测到已知攻击工具 | Pattern | CRITICAL | | PROC-002 | 可疑命令行 | Pattern | HIGH | | TIME-001 | 异常登录时间 | Threshold | LOW | ### 检测逻辑类型 **Threshold-based：** 当计数在时间窗口内超过限制时触发。示例：同一账户在 5 分钟内累计出现 5 次以上失败登录时，BF-001 会触发。 **Sequence-based：** 当事件 A 在时间窗口内随后发生事件 B 时触发。示例：当同一账户在经历大量失败登录后出现一次成功登录时，BF-002 会触发 —— 即攻击者成功进入的模式。 **Pattern-based：** 当事件内容与已知的恶意签名匹配时触发。示例：当 4688 事件的命令行中包含 `-enc` 时，PROC-002 会触发 —— 这是大多数商业恶意软件使用的编码 PowerShell 混淆模式。 ## 监控的 Windows 事件 ID | 事件 ID | 描述 | |----------|------------------------------------------| | 4624 | 成功登录 | | 4625 | 登录失败 | | 4634 | 注销 | | 4647 | 用户发起的注销 | | 4672 | 分配给登录的特殊权限 | | 4688 | 进程创建（包含命令行） | | 4719 | 审核策略更改 | | 4720 | 创建用户账户 | | 4726 | 删除用户账户 | | 4728 | 成员被添加到全局安全组 | | 4732 | 成员被添加到本地安全组 | | 4740 | 账户被锁定 | | 4756 | 成员被添加到通用安全组 | ## 环境设置 ### 前置条件 - Windows 10 或 Windows 11 - Python 3.10 或更高版本 - 需要管理员权限以收集日志 ### 安装 克隆仓库并设置虚拟环境： ``` git clone https://github.com/ThisaraKawinda/security-log-dashboard.git cd security-log-dashboard python -m venv venv venv\Scripts\activate pip install -r requirements.txt python venv\Scripts\pywin32_postinstall.py -install ``` ### 审核策略配置 在收集日志之前，以管理员身份运行以下命令以启用所需的 Windows 审核策略： ``` auditpol /set /subcategory:"Logon" /success:enable /failure:enable auditpol /set /subcategory:"Logoff" /success:enable auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable auditpol /set /subcategory:"Process Creation" /success:enable auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable auditpol /set /subcategory:"Special Logon" /success:enable ``` 通过组策略编辑器启用命令行参数记录： ``` gpedit.msc Computer Configuration Administrative Templates System Audit Process Creation Include command line in process creation events: Enabled ``` 验证命令行记录是否已激活： ``` reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled ``` 预期输出：`ProcessCreationIncludeCmdLine_Enabled = 0x1` ### 运行流水线 以管理员身份运行以收集日志并填充数据库： ``` python run_pipeline.py ``` ### 启动仪表板 ``` streamlit run dashboard/app.py ``` ### 生成安全报告 ``` python reports/report_generator.py ``` ## 项目结构 ``` security-log-dashboard/ | +-- collector/ | +-- __init__.py | +-- log_collector.py Windows Event Log collection via EvtQuery API | +-- parser/ | +-- __init__.py | +-- event_parser.py XML normalization and field extraction | +-- detection/ | +-- __init__.py | +-- rules.py Detection rules and alert generation | +-- storage/ | +-- __init__.py | +-- database.py SQLite storage layer | +-- dashboard/ | +-- app.py Streamlit interactive dashboard | +-- reports/ | +-- report_generator.py Automated Markdown report generation | +-- data/ | +-- sample_logs/ | +-- sample_report.md Sample generated security report | +-- screenshots/ Dashboard screenshots | +-- tests/ | +-- test_parser.py Unit tests | +-- config.py Central configuration and thresholds +-- run_pipeline.py End-to-end pipeline runner +-- requirements.txt +-- README.md ``` ## 关键技术决策 ### 分离查询架构 通过针对 Windows 事件日志 API 的独立 XPath 查询来收集身份验证和进程创建事件。这可以防止大量的进程遥测数据（在受监控的终端上每小时大约产生 1,700 个事件）在收集到数量较少但保真度更高的身份验证事件之前耗尽收集预算。这反映了生产级 SIEM 摄取流水线中使用的架构，其中高吞吐量的数据源在专用通道中进行处理。 ### 现代 Windows 事件日志 API 收集器使用现代 Windows 事件日志 API（Vista 及更高版本）中的 EvtQuery 和 EvtRender，而不是传统的 ReadEventLog 和 SafeFormatMessage 路径。这确保了每种事件类型都能返回完全结构化的 XML，从而无论事件来源如何，都能可靠地提取字段。 ### WAL 模式 SQLite 在 SQLite 数据库上启用了 Write-Ahead Logging，允许仪表板在收集器流水线写入时进行并发读取。这消除了在连续收集模式下的数据库锁定冲突。 ### 防止重复数据 (timestamp, event_id, computer) 上的 UNIQUE 约束与 INSERT OR IGNORE 结合使用，使得流水线可以安全地重复运行。多次执行 `run_pipeline.py` 不会创建重复记录。 ### 非规范化单表 所有事件类型都存储在一个表中，而不是按事件类别拆分。这简化了跨事件类型的相关性查询，这是安全仪表板中的主要查询模式。例如，将失败登录与同一用户随后执行的进程相关联只需要一个 SQL 查询，而不是跨多个表的 JOIN。 ### 事件和警报去重 检测规则作用于以 (timestamp, event_id, target_user, subject_user) 为键的去重后事件集。警报去重将同一逻辑事件中多次触发的规则合并为一个警报，从而减少了噪音并提高了分类效率。 ## 安全报告示例 可在此处查看自动生成的安全报告示例： [data/sample_logs/sample_report.md](data/sample_logs/sample_report.md) ## 经验教训 - Windows 审核策略和 Event ID 4688 的命令行记录是独立配置的。如果启用了“进程创建”审核却没有启用命令行包含功能，生成的事件将只显示进程名称，而不显示参数，这会让我们彻底丧失对编码 PowerShell 及其他基于命令行的攻击技术的可见性。 - 出于性能和存储的考虑，默认的 Windows 审核策略是刻意保持最简的。SOC 工程师必须为每个所需的事件类别显式配置遥测覆盖范围。 - 像进程创建 (4688) 这样高吞吐量的事件源，在活跃的工作站上每小时会生成大约 1,700 个事件。如果没有架构上的分离，这些事件会在几分钟内耗尽整个收集预算，导致在日志历史记录中无法读取到身份验证和账户管理事件。 - `gpupdate /force` 命令在独立工作站上可能会报告超时，即使策略实际上已成功应用。请务必通过直接查询注册表来验证策略应用情况，而不是单纯依赖 `gpupdate` 的退出状态。 - 针对可疑进程的单关键字模式匹配会产生大量误报。有效的检测要么需要高置信度的单一指标（例如编码的 PowerShell `-enc` 标志），要么需要对多个较低置信度的指标进行组合评估。 ## 审核策略还原 要在项目完成后将审核策略还原为 Windows 默认设置： ``` auditpol /set /subcategory:"Logon" /success:enable /failure:disable auditpol /set /subcategory:"Account Lockout" /success:enable /failure:disable auditpol /set /subcategory:"User Account Management" /success:enable /failure:disable auditpol /set /subcategory:"Security Group Management" /success:disable /failure:disable auditpol /set /subcategory:"Process Creation" /success:disable auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:disable auditpol /set /subcategory:"Special Logon" /success:disable ``` ## 作者 Thisara Kawinda 信息技术系统计算机荣誉学士 (B.Computing) 斯里贾亚瓦德纳普拉大学，科伦坡，斯里兰卡 github.com/ThisaraKawinda ## 许可证 MIT 许可证

标签：Kubernetes, Python, SIAM, Streamlit, Windows事件日志, 代码共享, 安全运营, 扫描框架, 无后门, 红队行动, 访问控制, 逆向工具