Đừng vẽ graph nếu chưa có câu hỏi điều tra

Đừng vẽ graph nếu chưa có câu hỏi điều tra

Graph intelligence chỉ hữu ích khi nó giúp team ra quyết định điều tra nhanh hơn. Đây là playbook triển khai theo lớp, không chạy theo demo màu mè.

Bạn có từng thấy một dashboard graph security đẹp mê chưa? Node xanh đỏ bay lượn, edge chằng chịt, zoom vào thấy user, device, IP, service nối nhau như tấm vải bị kéo căng. Cả team nhìn 5 phút rồi im lặng: “Rồi giờ mình bắt đầu điều tra từ đâu?”

Đó là chỗ nhiều pipeline graph analytics bị lệch đường. Vấn đề không phải thiếu PyGraphistry, NetworkX, community detection hay layout embedding. Vấn đề là team dựng graph như một màn hình trình diễn, trong khi security analytics cần một quy trình điều tra.

Luận điểm của mình: đừng triển khai graph intelligence như một visualization project; hãy triển khai nó như một investigation workflow có điểm vào, điểm dừng, và bằng chứng kiểm tra được.

Sơ đồ minh họa cho bài Đừng vẽ graph nếu chưa có câu hỏi điều tra

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu thật: graph phải trả lời câu hỏi vận hành

PyGraphistry cho phép dựng workflow tương tác khá mạnh: tạo dataset kiểu enterprise access, biến event thành node/edge, tính risk score, anomaly indicator, centrality, community detection, rồi bind màu sắc, label, tooltip và filtered subgraph để điều tra user, device, IP, service nhạy cảm.

Nhưng builder cần hỏi ngược lại trước:

Khi incident xảy ra, graph này giúp analyst làm gì trong 10 phút đầu?

Nếu câu trả lời chỉ là “nhìn quan hệ trực quan hơn”, chưa đủ. Câu trả lời nên cụ thể hơn, ví dụ:

Graph intelligence ở đây nghĩa là dùng cấu trúc quan hệ để hỗ trợ điều tra, không chỉ lưu dữ liệu dạng bảng rồi tô màu cho vui. Sợi ngang là event, sợi dọc là entity; nếu không biết mình đang dệt mẫu gì, bạn chỉ có một cuộn chỉ rối rất đắt công xem.

Checklist trước khi mở notebook

Trước khi cài PyGraphistry hay chạy Colab, mình sẽ bắt team đi qua checklist này. Hơi khô, nhưng đỡ mất một buổi chiều vào hình đẹp mà không dùng được.

| Câu hỏi | Quyết định cần chốt | Nếu bỏ qua sẽ sao |
|---|---|---|
| Entity chính là gì? | user, device, IP, service, role, geo | Graph phình to nhưng không có điểm neo |
| Edge đại diện cho quan hệ nào? | access, login, failure, ownership, role mapping | Nối sai quan hệ, suy luận sai |
| Risk score tính ở đâu? | event, edge, node, hay cả ba | Tooltip nhiều số nhưng không biết tin số nào |
| Analyst bắt đầu từ đâu? | user đáng nghi, IP rủi ro, alert ID, service nhạy cảm | Graph thành bản đồ không có lối vào |
| Khi nào dừng điều tra? | đủ bằng chứng, không có đường tới asset nhạy cảm, cần escalated case | Cứ zoom mãi, không ra quyết định |

Một điểm đáng học từ các workflow liên quan như Graphify + NetworkX cho codebase là: graph có ích nhất khi nó phản ánh quan hệ thật của hệ thống. Với codebase, đó là import, function call, class, module, database object. Với security, đó là access event, device usage, IP, role, service, location. Đừng ép mọi thứ thành một loại edge chung chung tên related_to rồi mong centrality cứu mình.

Bóc hệ thống theo 5 lớp triển khai

Đây là playbook mình sẽ dùng nếu phải dựng bản thử nghiệm trong một buổi chiều cho team security hoặc platform.

Lớp 1: event thô phải giữ được dấu vết

Đầu vào nên là bảng event có ít nhất các cột kiểu:

timestamp, user_id, device_id, ip, service, role, geo,
action, success, failure_reason, risk_hint

Nếu đang dùng dữ liệu synthetic để test như trong tutorial, ổn. Nhưng khi đi production, đừng chỉ giữ bản đã aggregate. Bạn cần quay lại event gốc để kiểm chứng vì graph rất dễ tạo cảm giác “đã thấy quan hệ là đã có bằng chứng”.

Ví dụ cụ thể: một edge user_A -> service_payroll có risk cao. Nếu tooltip chỉ hiện “risk=high”, analyst vẫn phải hỏi: high vì đăng nhập ngoài giờ, vì IP lạ, vì failure nhiều, hay vì role không khớp? Không có event gốc, graph chỉ là mũi chỉ đẹp nhưng không khâu được hồ sơ điều tra.

Lớp 2: node/edge cần schema rõ

Node là thực thể: user, device, IP, service, role, geography. Edge là quan hệ có hướng hoặc không hướng giữa các thực thể: user dùng device, device xuất hiện ở IP, user truy cập service.

Gợi ý schema tối thiểu:

nodes:
  id, type, label, risk_score, anomaly_flag, first_seen, last_seen

edges:
  source, destination, relationship,
  count, failures, max_risk, first_seen, last_seen,
  sample_actions

Đừng nhồi mọi metadata vào node. user_A không “rủi ro” theo cùng cách với ip_1.2.3.4. Risk của user có thể đến từ hành vi; risk của IP có thể đến từ reputation; risk của service có thể đến từ độ nhạy cảm. Cùng một cột risk_score được, nhưng công thức và tooltip phải giải thích khác nhau theo type.

Lớp 3: metric không phải phán quyết

Các metric như centrality — mức độ một node nằm ở vị trí quan trọng trong graph — và community detection — gom node thành cụm có liên kết dày — rất hữu ích để ưu tiên xem trước. Nhưng chúng không thay cho điều tra.

Một device có centrality cao có thể là jump box hợp lệ. Một IP nối nhiều user có thể là VPN gateway. Một community nhìn đáng sợ có thể chỉ là team finance dùng chung bộ service cuối tháng.

Vì vậy, mình thích chia metric thành 3 nhóm:

Nếu dashboard trộn cả ba thành một màu đỏ duy nhất, analyst sẽ bị kéo mắt theo màu chứ không theo chứng cứ.

Lớp 4: visualization phải phục vụ thao tác lọc

PyGraphistry mạnh ở interactive visualization: bind màu theo risk, kích thước theo centrality, label theo entity, tooltip theo metadata, rồi lọc subgraph để nhìn phần liên quan.

Nhưng phần đáng tiền không phải “graph xoay mượt”. Phần đáng tiền là analyst có thể làm những thao tác này nhanh:

1. Chọn một suspicious user
2. Hiện device, IP, service trong 24-72 giờ gần nhất
3. Highlight service nhạy cảm
4. Ẩn edge có count thấp hoặc risk thấp
5. Mở rộng 1 hop sang role và geo
6. Export danh sách event cần kiểm chứng

Filtered subgraph — graph con sau khi lọc theo điều kiện — nên là trung tâm của workflow. Full graph thường chỉ để định hướng. Điều tra thật diễn ra ở graph con đủ nhỏ để con người đọc được.

Lớp 5: offline fallback là yêu cầu vận hành, không phải bonus

Nguồn chính có nhắc việc tạo local interactive visualization khi chưa cấu hình Graphistry credentials. Chi tiết này nhỏ nhưng rất thực tế.

Nhiều team Việt Nam triển khai trong môi trường hạn chế outbound, dữ liệu security không được đẩy ra ngoài, hoặc notebook chạy trong VPC nội bộ. Nếu workflow chỉ chạy đẹp khi có cloud credential, nó sẽ kẹt ngay lúc cần demo cho security lead.

Tối thiểu nên có 2 mode:

local_mode:
  - tạo HTML/plot local
  - dùng sampled graph
  - không gửi dữ liệu ra ngoài

hub_mode:
  - dùng Graphistry Hub nếu policy cho phép
  - graph lớn hơn
  - chia sẻ investigation view cho nhiều người

Đây không phải chuyện “open-source hay cloud tốt hơn”. Đây là chuyện luồng điều tra có sống nổi trong ràng buộc bảo mật của công ty bạn không.

Pitfall: graph đẹp làm team quên data hygiene

Có một lỗi mình thấy lặp lại: team chăm layout, màu sắc, community, nhưng bỏ qua chuẩn hóa dữ liệu.

Bài OCRmyPDF gợi một bài học khá xa mà gần: trước khi đưa tài liệu vào search hay extraction, phải có text layer, validation, batch processing, xử lý scan nhiễu, file đã OCR rồi thì không làm bừa. Với graph security cũng vậy. Trước khi visualize, bạn cần dọn lớp dữ liệu:

Nếu không, graph sẽ vá víu các mảnh dữ liệu lệch chuẩn thành một bức tranh tưởng liền mạch. Nhìn thì ổn, điều tra thì dễ lệch.

Một pitfall khác: dùng LLM/agent quá sớm để “giải thích graph”. Tool calling — model gọi công cụ/API thay vì chỉ trả lời bằng chữ — có thể hữu ích khi analyst hỏi “liệt kê các đường đi từ user này tới service nhạy cảm”. Nhưng nếu schema, metric, và evidence chưa chắc, agent chỉ diễn giải cái sai bằng giọng tự tin hơn.

Nếu là mình, mình sẽ triển khai bản đầu như sau

Giả sử team bạn có một buổi chiều để làm proof-of-concept, mình sẽ không cố dựng platform hoàn chỉnh. Mình sẽ chọn một câu hỏi điều tra duy nhất:

“User đáng nghi có đường liên hệ nào tới service nhạy cảm trong khoảng thời gian gần incident không?”

Sau đó làm 5 việc:

  1. Lấy 1 lát dữ liệu nhỏ: vài ngày access log, có user, device, IP, service, role, timestamp, success/failure.
  2. Định nghĩa schema node/edge: không quá 6 loại node, không quá 5 loại relationship.
  3. Tính metric vừa đủ: count, failures, max risk, first/last seen, degree/centrality cơ bản.
  4. Dựng 3 view cố định: user-centric, service-centric, IP-centric.
  5. Export evidence: mỗi edge trong graph phải dẫn được về danh sách event gốc.

Chỉ khi bản này giúp analyst trả lời câu hỏi nhanh hơn, mình mới thêm community detection, layout embedding, long-context explanation, hoặc agent hỏi đáp.

Sau bài này, điểm mình muốn bạn nghĩ khác là: graph không phải đích đến của pipeline; graph là giao diện điều tra cho một chuỗi quyết định đã được thiết kế trước. Đừng bắt analyst ngồi gỡ một cuộn chỉ rối rồi gọi đó là intelligence.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo