Tự dựng AiSOC để hợp nhất alert và truy vết quyết định khi trực incident

AiSOC là SOC mã nguồn mở tự host: nhận telemetry, chạy rule, tương quan alert và dùng AI agent để triage với prompt तथा tool call được ghi lại. Đáng để đội DevOps/SRE thử trong lab trước khi cân nhắc tích hợp sâu.

Một alert “Encoded PowerShell from Office” bật lên giữa ca trực. EDR báo một kiểu, SIEM báo một kiểu, CloudTrail hoặc Kubernetes audit log lại nằm ở nơi khác.

Việc khó không chỉ là phát hiện. Đó là ghép đủ ngữ cảnh, biết kết luận được đưa ra dựa trên dữ liệu nào và giữ quyền phê duyệt ở con người trước khi có phản hồi ra hệ thống bên ngoài.

AiSOC là dự án SOC mã nguồn mở, tự host, đang được chú ý trên GitHub. Dự án hướng tới một workflow khép kín: nhận telemetry, phát hiện và tương quan mối đe doạ, để AI agent hỗ trợ triage, đồng thời lưu lại prompt và tool call của agent để có thể kiểm tra lại.

Với DevOps, SRE và platform engineer, đây không chỉ là thêm một dashboard bảo mật. Nó gần với một pipeline xử lý incident có kiểm chứng: có đầu vào, các bước xử lý, bằng chứng và điểm phê duyệt rõ ràng.

Từ alert rời rạc đến incident có thể kiểm tra lại

Theo README, AiSOC chuẩn hoá security telemetry, chạy rule phát hiện, nhóm các kết quả kích hoạt thành incident và dùng AI agent để điều tra. Agent có thể đề xuất phản hồi, nhưng con người phải phê duyệt trước khi phản hồi được gửi sang vendor.

Điểm đáng chú ý là khả năng truy vết quyết định: mỗi prompt và tool call của agent đều được ghi lại. Thay vì chỉ nhận một verdict như “nghi ngờ độc hại”, người trực có thể xem lại agent đã được cung cấp gì và đã gọi những công cụ nào trong quá trình triage.

Dự án công bố thư viện gồm 7.015 rule, trong đó có 2.530 rule thực thi được. Threat intelligence mới cũng có thể được dùng để quét lại dữ liệu lịch sử đã thu thập. Console hiển thị catalog CISA KEV mà không cần API key.

Giá trị với đội trực

Khi phải review một incident hoặc viết postmortem, audit trail giúp giảm phụ thuộc vào Slack, dashboard rời rạc và trí nhớ của người on-call. Đây là hướng tiếp cận thực tế hơn việc để LLM tự xử lý incident: AI có thể tăng tốc triage, nhưng bằng chứng và human approval mới là điều kiện để đưa nó vào quy trình vận hành.

Dựng trên một host: hãy bắt đầu từ lab

README công bố AiSOC có thể tự host và chạy luồng cơ bản không cần API key. Yêu cầu gồm Docker Compose v2, Docker VM có 8 GB RAM và 20 GB đĩa trống, cùng python3 từ 3.9 trở lên và bash.

Lần chạy đầu sẽ tải một model cục bộ khoảng 2 GB vào volume.

Trên máy đã có sẵn các phụ thuộc, luồng cài đặt nhanh là:

bash git clone https://github.com/beenuar/AiSOC && cd AiSOC make up

Lệnh này tạo file .env, sinh 15 secret, tạo tài khoản quản trị và in mật khẩu một lần. README cho biết mật khẩu được tạo trên máy cài đặt và không được lưu để hiển thị lại.

Nếu mất mật khẩu, dự án nêu lệnh reset sau:

bash make bootstrap ARGS=--reset-password

Trước khi dựng stack, hãy chạy kiểm tra môi trường:

bash make doctor

Sau khi stack hoạt động, đừng chỉ kiểm tra container có trạng thái “healthy”. Hãy chạy smoke test của dự án:

bash make smoke

Smoke test gửi một event vào ingest API, theo dõi event qua Kafka, detection, correlation và Postgres, sau đó đọc alert từ public API. Mỗi chặng báo PASS hoặc FAIL.

Với platform team, có thể xem make doctor như preflight check, còn make smoke như synthetic transaction cho pipeline SOC. Đây là hai kiểm tra hữu ích để đưa vào runbook triển khai nội bộ.

> README cũng cung cấp script cài đặt một dòng cho Windows, Linux và macOS. Với môi trường có quyền cao, nên review script và thử trong lab cô lập trước khi sử dụng.

Walkthrough: gửi event và theo dõi pipeline

Sau khi make up in địa chỉ console và bạn đăng nhập, wizard cho phép nạp sample data. Năm scenario mẫu đi qua cùng ingest path với connector thực, thay vì chèn trực tiếp vào database.

Các mẫu này được gắn nguồn AiSOC, không nạp vào tenant đã có alert thực và không đánh dấu hoàn tất quá trình setup.

Bạn cũng có thể gửi event kiểm thử của riêng mình. Trước hết, tạo ingest credential:

bash make ingest-token

Sau đó gửi event qua API:

bash curl -X POST http://localhost:8081/v1/ingest/batch \ -H 'Content-Type: application/json' -H "Authorization: Bearer $AISOCINGESTTOKEN" \ -d '{"connectorid":"edr-1","connectortype":"crowdstrike","events":[{"severity":"high", "title":"Encoded PowerShell from Office","host":"WIN-FIN-01"}]}'

Khi kiểm tra trên console, hãy tập trung vào ba câu hỏi:

Event có được gắn đúng connector và nguồn dữ liệu không? Nó có trở thành alert và được correlation nhóm vào incident không? Khu vực điều tra có hiển thị verdict, confidence, rationale cùng dấu vết hoạt động của agent không?

Không đưa token thật, secret, kubeconfig hoặc log nhạy cảm vào prompt AI, ticket công khai hay kênh chat ngoài vùng kiểm soát. Khi cần review mapping, hãy dùng schema đã khử định danh, hostname giả và placeholder cho thông tin bí mật.

Kết nối cloud, SIEM và Kubernetes audit

AiSOC công bố 87 connector click-and-connect, gồm Splunk, Sentinel, Elastic, CrowdStrike, Okta, AWS và Kubernetes audit. Khi không có vendor profile, hệ thống vẫn có generic mapping để nhận diện host, user và source IP.

Với cloud estate, dự án nêu bốn collector:

CloudTrail organization trail trên S3, nhận thông báo qua SQS; GCP Pub/Sub từ Cloud Logging sink; Azure Event Hubs capture; Syslog/CEF listener.

Các collector giữ resumable cursor và giới hạn ngân sách mỗi lần poll, nhằm để backlog tạo backpressure thay vì làm ngập ingest.

Đây là chi tiết đáng chú ý với SRE: một SOC pipeline cũng là event-driven system. Khi thử nghiệm, nên quan sát backlog, retry, cursor và ảnh hưởng khi các thành phần downstream như Kafka hoặc Postgres gặp vấn đề.

Migration rule: đừng coi là thao tác “một lần là xong”

Dự án có gói migration cho Splunk SPL, Sentinel KQL và Elastic EQL. Với rule không thể chuyển chính xác, công cụ được mô tả là sẽ từ chối thay vì xấp xỉ.

Trong 2.005 Splunk rule đi kèm, README nêu 1.734 rule chuyển được; 1.711 trong số đó được đánh dấu là partial theo định nghĩa của dự án.

Với đội đã có SIEM, đây là tín hiệu để lập kế hoạch migration theo từng lớp:

Inventory rule hiện có. Phân loại rule chuyển được, partial và bị từ chối. Review lại logic phát hiện với security team. Kiểm thử bằng telemetry mẫu trước khi áp dụng vào luồng vận hành.

Hãy xem một thay đổi detection rule giống thay đổi IaC có blast radius lớn: cần review, kiểm thử và có rollback rõ ràng.

Ranh giới cần giữ khi đưa AI vào ca trực

AiSOC có MCP server cho Claude, Cursor và Continue. Dù dùng giao diện hay tích hợp MCP, nguyên tắc vận hành vẫn nên nhất quán: giới hạn quyền truy cập, giảm thiểu dữ liệu nhạy cảm đưa vào AI và giữ phê duyệt của con người cho mọi phản hồi có tác động.

Checklist thử nghiệm an toàn:

[ ] Dựng trước trong lab hoặc tenant cô lập. [ ] Chạy make doctor trước triển khai và make smoke sau triển khai. [ ] Nạp sample data trước, rồi mới thử telemetry đã khử định danh. [ ] Kiểm tra dấu vết prompt và tool call ở các verdict quan trọng. [ ] Giữ human approval cho mọi hành động phản hồi. [ ] Review connector mapping, quyền truy cập và dữ liệu gửi vào AI. [ ] Không đưa secret, token, kubeconfig hoặc log nhạy cảm vào công cụ AI.

AiSOC không thay thế on-call engineer hay SOC analyst. Giá trị đáng thử của dự án nằm ở việc đưa AI triage vào một quy trình có bằng chứng, có khả năng kiểm tra lại và có điểm phê duyệt rõ ràng — những yếu tố thiết yếu khi incident cần được giải thích sau khi ca trực kết thúc.