Building Slack's Anomaly Event Response

Slack · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài giới thiệu tính năng bảo mật cho khách Enterprise Grid; ít số liệu vận hành.

Bối cảnh

Slack đã có audit log loại anomaly (đăng nhập bất thường, tải malware, truyền dữ liệu bất thường) nhưng khách phải tự xem hoặc tích hợp vào công cụ bảo mật; nhiều tổ chức không đủ nguồn lực. Khoảng cách phát hiện → phản ứng có thể là ngày hoặc giờ.

AER tự động chấm dứt mọi session của user khi phát hiện hành vi rủi ro cao; mục tiêu rút khoảng cách xuống vài phút.
Bộ phát hiện chọn theo độ phổ biến: truy cập từ Tor exit node, tải quá nhiều (dấu hiệu exfiltration), scraping bằng công cụ không phải của Slack, session fingerprint không khớp, khối lượng/mẫu API bất thường, user agent lạ. Tổ chức tự chọn phát hiện nào kích hoạt phản ứng, phát hiện nào chỉ ghi log.
Ba thành phần: engine phát hiện trên hàng tỉ event/ngày, kết hợp luật và ngưỡng động tính theo lịch sử từng tổ chức (cái bất thường ở tổ chức này là bình thường ở tổ chức khác); khung quyết định kiểm cấu hình khách và xem các payload trước đó để phát hiện kẻ tấn công vẫn tiếp tục sau khi bị cắt session, đồng thời tránh vòng lặp cắt session user hợp lệ; điều phối phản ứng chạy qua job bất đồng bộ.
Mỗi lần phản ứng ghi audit log riêng (user_sessions_reset_by_anomaly_event_response) kèm loại anomaly và session_id gốc; email cho user, thông báo cho Org Owner/Security Admin theo cấu hình, gộp khi một người giữ nhiều vai trò.

Theo Slack, đưa phản ứng tự động vào nền tảng cho mọi khách, khách lớn vẫn tự xây thêm lớp riêng.