AiSOC tự host: SOC AI mã nguồn mở cho blue team

Một ca trực SOC nhỏ hiếm khi bắt đầu bằng một cuộc tấn công lớn. Nó bắt đầu bằng hàng chục cảnh báo rời rạc từ EDR, firewall, cloud và identity, mỗi cảnh báo nằm ở một console khác nhau. Người trực không thiếu dữ liệu. Họ thiếu một nơi để nhìn toàn bộ câu chuyện và quyết định việc nào xử lý trước.

AiSOC sinh ra cho khoảng trống đó. Đây là SOC mã nguồn mở, tự host, dùng AI để gom cảnh báo, tương quan sự kiện và điều tra. Nguyên tắc quan trọng nhất của nó là: AI đề xuất, con người phê duyệt, rồi mới có hành động. Thông tin trong bài được kiểm chứng ngày 2026-11-02 với bản v21.0.0. Dự án phát hành rất nhanh, từ v20.3.0 ngày 2026-10-30 lên v21.0.0 chỉ trong hai ngày, nên trước khi cài, bạn vẫn nên đối chiếu lại README và changelog mới nhất. Nói thẳng từ đầu: phần cài đặt trong bài mình chưa chạy thử trong lab, chỉ đối chiếu với tài liệu chính thức.

1. AiSOC là gì?

AiSOC là nền tảng SOC mã nguồn mở, giấy phép MIT, viết bằng Python, tại kho beenuar/AiSOC. Tại thời điểm kiểm tra 2026-11-02, dự án có khoảng 6.548 stars và 671 forks, tạo từ ngày 2026-05-02 và vẫn cập nhật tích cực. Con số này chỉ phản ánh mức độ quan tâm của cộng đồng, không phải bằng chứng về chất lượng phát hiện.

AiSOC không phải EDR, firewall, và không thay thế SIEM đang thu thập log gốc của bạn. Nó là lớp phía trên các nguồn đó: thu thập telemetry, chuẩn hóa về định dạng chung, chạy thư viện quy tắc, gom các lần kích hoạt thành incident, rồi dùng AI agent điều tra và đề xuất bước xử lý. Đề xuất đó phải qua phê duyệt của con người trước khi chạm tới bất kỳ hệ thống nào của nhà cung cấp.

AiSOC giải quyết triage, tương quan đa nguồn và khả năng giải trình qua prompt và tool call được ghi lại.

Ngược lại, AiSOC không tạo log từ hạ tầng không có log, không phản ứng tự động hoàn toàn, và chưa có benchmark độc lập nào về độ chính xác hay hiệu năng.

AiSOC phù hợp nhất với sysadmin, DevOps/SRE, kỹ sư SOC và blue team, và người chơi homelab đã quen Docker, đang có ít nhất hai nguồn telemetry và muốn một console phòng thủ chung. Nếu bạn chỉ có một nguồn log, SIEM nhẹ hoặc chính console của nguồn đó đã đủ. Bạn cũng không nên dùng AiSOC trên VPS nhỏ dùng chung, cho đội không có người trực phê duyệt, hoặc khi tổ chức yêu cầu SLA và hỗ trợ chính thức. Về phía tấn công để đối chiếu, bài về Shannon, AI pentester cho web và API là phía đối tác: Shannon tìm lỗ hổng từ bên ngoài, AiSOC tổ chức phòng thủ từ bên trong.

2. Kiến trúc và cơ chế hoạt động

Luồng dữ liệu đi theo chuỗi rõ ràng: nguồn telemetry gửi dữ liệu qua collector hoặc connector, tới ingest API, được chuẩn hóa, rồi đưa vào Kafka. Detection engine chạy thư viện quy tắc, correlation gom các lần kích hoạt liên quan thành incident, kết quả lưu vào Postgres. Từ incident, AI agent điều tra và đề xuất một hành động, và hành động chỉ đi tới nhà cung cấp sau khi con người phê duyệt. Nhờ cổng phê duyệt này, chế độ lỗi của một lần triage sai là một incident nằm chờ trong hàng đợi, chứ không phải một lệnh remediation tự động gửi nhầm tới hệ thống production.

Ở tầng thu thập, dự án nêu bốn collector: CloudTrail qua S3 và SQS, GCP qua Pub/Sub, Azure Event Hubs và syslog/CEF listener. Mục Settings → Connectors có 91 connector, gồm Splunk, Sentinel, Elastic, CrowdStrike, Okta, AWS và Kubernetes audit; một số nguồn có chuẩn hóa riêng, số còn lại dùng mapping chung, và mapping chung là nơi triage dễ suy giảm nhất.

Detection engine đi kèm thư viện 7.023 quy tắc, trong đó 2.538 quy tắc thực thi được. Nhiều quy tắc ở dạng tham chiếu, cần điều kiện nguồn cụ thể, hoặc chưa đủ dữ liệu chuẩn hóa để chạy. Khi đánh giá độ phủ, hãy nhìn con số thực thi được, không phải tổng số.

Lớp threat intelligence đi kèm catalog CISA KEV, có sẵn vài phút sau khi boot mà không cần API key, và tái quét lịch sử khi có threat intel mới. Công cụ migration packages/aisoc-migrate dịch quy tắc Splunk SPL, Sentinel KQL và Elastic EQL, đồng thời từ chối phần không dịch được; tài liệu của dự án ghi rằng trong 2.005 quy tắc Splunk kèm theo, 1.734 quy tắc dịch được và 1.711 trong số đó chỉ dịch một phần, nên quy tắc đã migration vẫn cần rà soát.

AiSOC gắn mỗi alert và incident với kỹ thuật MITRE ATT&CK, giúp blue team ưu tiên theo tactic và technique thay vì chỉ nhìn severity. Theo mình, rủi ro chính của AiSOC không phải AI bịa kết luận, mà là nợ chuẩn hóa: triển khai trên các nguồn mapping kém thì bạn chỉ tái tạo tình trạng mệt mỏi vì cảnh báo cũ trong một giao diện đẹp hơn.

3. Tự host AiSOC bằng Docker

Điều kiện tiên quyết

Theo tài liệu chính thức, bạn cần Docker Compose v2, Python 3.9 trở lên và bash, cùng 8 GB RAM và 20 GB đĩa trống trong Docker VM. Con số này loại trừ ngay VPS 2 GB RAM dùng chung, nên theo mình, hãy dùng một máy chủ hoặc VM riêng cho AiSOC, và dự trù thêm thời gian và băng thông cho lần tải model khoảng 2 GB. Phiên bản tham chiếu là v21.0.0, kiểm chứng ngày 2026-11-02.

Cài đặt

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

Trước đó, kiểm tra điều kiện tiên quyết bằng make doctor. Lệnh make up tạo file .env, sinh secret, tạo tài khoản quản trị và in mật khẩu được sinh ra một lần. Hãy lưu mật khẩu này ngay vào trình quản lý mật khẩu, đừng đăng công khai hay dán vào chat nhóm. Nếu làm mất mật khẩu, đặt lại bằng make bootstrap ARGS=--reset-password. Dự án cũng cung cấp installer một dòng qua install.sh và install.ps1; theo mình, hãy ưu tiên cách clone và make up, và nếu dùng installer dạng pipe sang shell thì đọc script trước khi chạy. Lưu ý về cổng: nếu cổng mặc định đã bị chiếm, AiSOC sẽ công bố trên một cổng trống và in địa chỉ console mới, nên đừng hard-code một cổng duy nhất trong tài liệu nội bộ.

Kiểm chứng sau cài đặt

make smoke

Lệnh này gửi một event thật qua ingest API và theo dõi nó đi qua Kafka, detection, correlation và Postgres. Output mẫu kết thúc bằng PASS: 10/10 stages. Nếu smoke test chưa pass, đừng vội nối nguồn thật. Nếu chỉ muốn xem AiSOC hoạt động ra sao mà không cần Docker, chạy pip install aisoc-sandbox && aisoc-sandbox demo — bản demo đưa một alert đi qua funnel trong chưa đầy 30 giây, chạy offline. Để học an toàn, setup wizard có nút Load sample data với năm kịch bản đi qua ingest thật, và hệ thống từ chối nạp dữ liệu mẫu vào tenant đã có alert thật; lệnh make demo nạp dataset tổng hợp lớn hơn, trong đó mọi dòng đều được đánh dấu is_synthetic = true.

Để gửi một event mẫu qua ingest API, trước hết lấy token bằng make ingest-token. Sau đó gửi request tới địa chỉ ingest mà hệ thống in ra lúc cài đặt, ví dụ:

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

Cổng 8081 ở đây chỉ là ví dụ theo tài liệu; hãy dùng cổng mà hệ thống của bạn công bố. Token ingest là bearer credential, nên đừng dán nó vào log, chat công khai hay ticket.

Kết nối nguồn đầu tiên

Thứ tự mình khuyên dùng: chạy smoke test cho pass, nạp sample data ở tenant lab, kết nối một nguồn thật có lưu lượng thấp, rồi mới mở rộng sang EDR, cloud và identity. Với mỗi nguồn, kiểm tra mapping chuẩn hóa của nó trước khi tin vào kết quả triage. Checklist tối thiểu: backup volume Postgres và Kafka cùng file .env, luân chuyển ingest token theo lịch, đặt console sau reverse proxy với HTTPS, và không phơi console trực tiếp ra internet.

4. Đánh giá

Ưu điểm rõ nhất: mã nguồn mở MIT, tự host, dữ liệu ở lại hạ tầng của mình, model chạy local thay vì gửi telemetry ra SaaS bên ngoài. Lớp triage và correlation giảm nhiễu đa nguồn, audit trail cho AI phù hợp với SOC cần giải trình, và công cụ migration giúp đội đang dùng SIEM cũ thử nghiệm mà không viết lại toàn bộ quy tắc.

Nhược điểm và chi phí ẩn cũng cần nói thẳng. Vận hành Kafka, Postgres, model khoảng 2 GB và yêu cầu 8 GB RAM khiến AiSOC nặng hơn hẳn một app Docker đơn lẻ. Bạn trả bằng thời gian backup, giám sát và nâng cấp thay vì trả phí SaaS. Chất lượng phụ thuộc vào nguồn đầu vào và mapping, và quy tắc dịch một phần có thể cho kết quả khác kỳ vọng nếu không rà soát. Nhịp release nhanh và chưa có dấu hiệu LTS khiến auto-upgrade production là ý tưởng tồi. Về hiệu năng, bài này chỉ nêu những con số đã có nguồn — 8 GB RAM, 20 GB đĩa, model khoảng 2 GB và smoke test 10 stage — và không nêu TPS, EPS hay độ trễ vì không có tài liệu đo đạc cho các con số đó.

Về bảo mật, ba loại credential cần quản lý chặt: mật khẩu quản trị in một lần, secret trong .env, và ingest token dạng bearer. Console, ingest API và MCP server đều phải đặt sau xác thực, reverse proxy và HTTPS. Human approval là kiểm soát an toàn chính, nhưng cũng là điểm nghẽn: nếu hàng đợi phê duyệt tồn đọng vì không có người trực, incident vẫn chậm dù AI triage nhanh đến đâu.

5. So sánh với các lựa chọn cùng phạm vi

Tiêu chí so sánh: phạm vi, mô hình triển khai, chi phí, connector và mapping, quy tắc và MITRE ATT&CK, audit trail, phê duyệt con người, độ nặng hạ tầng và độ trưởng thành cộng đồng.

6. Use case thực tế

Với doanh nghiệp vừa và SOC nội bộ nhỏ, AiSOC gom alert về một hàng đợi incident, ca trực phê duyệt theo mức độ, và audit trail phục vụ báo cáo sau sự cố. Với homelab, giá trị nằm ở lab an toàn bằng sandbox và sample data trước khi nối log thật. Với blue team dùng AI workflow, MCP server cho phép truy vấn SOC từ Claude, Cursor hay Continue, nhưng vẫn giữ phê duyệt con người. Với DevOps/SRE, hai tính năng đáng giá nhất là tái quét lịch sử khi có CISA KEV mới và migration từ Splunk, Sentinel hay Elastic.

7. Xử lý lỗi, backup và rollback

Thiếu RAM hoặc đĩa, Docker VM không đủ 8 GB hoặc 20 GB, là lỗi đầu tiên cần loại trừ: tăng tài nguyên rồi kiểm tra lại bằng make doctor. Cổng mặc định bị chiếm không phải lỗi: hãy dùng địa chỉ console mà AiSOC in ra. Lần boot đầu chậm thường do tải model khoảng 2 GB: hãy chờ, kiểm tra log và volume, và tuyệt đối không chạy make clean giữa chừng vì lệnh này xóa model và volume. Mất mật khẩu quản trị thì dùng make bootstrap ARGS=--reset-password.

Về backup, tối thiểu cần sao lưu volume Postgres và Kafka cùng file .env, và kiểm tra khả năng khôi phục bằng cách dựng lại ở lab. Chưa có quy trình rollback chính thức trong tài liệu mình đã đọc, nên trước nâng cấp hãy snapshot volume Postgres/Kafka và .env, giữ bản compose và cấu hình cũ, thử ở lab trước, và chạy lại make smoke sau rollback.

8. Kết luận

AiSOC nên dùng cho đội đã có từ hai nguồn telemetry trở lên, muốn một lớp triage tự host có thể kiểm chứng, chấp nhận vận hành Kafka và Postgres, và có ca trực phê duyệt. Nó không nên dùng cho máy yếu, cho nhu cầu xem log đơn nguồn, cho đội muốn phản ứng tự động không cần người duyệt, hoặc cho tổ chức cần SIEM thương mại có SLA và hỗ trợ chính thức.

Nếu bạn muốn thử, lộ trình cụ thể là: chạy sandbox demo, rồi make doctor, make up ở lab, make smoke đạt PASS 10/10, nạp sample data, nối một nguồn thật lưu lượng thấp, rồi mới mở rộng. Trước khi mở production, tự kiểm tra năm câu hỏi: tài nguyên đã đủ chưa, token và mật khẩu đã lưu an toàn chưa, tenant lab đã tách tenant thật chưa, cổng và HTTPS đã khóa chưa, và đã đọc changelog v21.0.0 chưa.

Tài liệu tham khảo

• Kho chính thức AiSOC: https://github.com/beenuar/AiSOC
• Tài liệu chính thức AiSOC: https://beenuar.github.io/AiSOC/
• Bài viết liên quan trên phamnam.me: Shannon, AI pentester cho web và API — https://phamnam.me/posts/shannon-ai-pentester-web-app-api/