Xây dựng quy trình phản hồi sự cố hỗ trợ bởi AI trong n8n
Viraj từng phụ trách mảng Customer Success tại n8n, nơi anh hỗ trợ các khách hàng doanh nghiệp trong lĩnh vực viễn thông, chính phủ, tài chính và các ngành khác áp dụng n8n và triển khai thành công trên các phòng ban chủ chốt. Anh đã dành nhiều thời gian làm việc với các lãnh đạo an ninh mạng và dựa trên kinh nghiệm này để chia sẻ dưới đây.
Dmitry là Kỹ sư Phát hiện và Tự động hóa An ninh với nền tảng về kỹ thuật phát hiện, tự động hóa SecOps và an ninh đám mây. Anh đã có nhiều năm kinh nghiệm ở phía đội xanh (blue team), xây dựng và đánh giá các công cụ bảo mật trên môi trường đám mây, và dựa trên kinh nghiệm này để đồng tác giả bài viết.
Các đội phản ứng sự cố đang phải đối mặt với một loạt vấn đề hiếm khi tự bộc lộ. Chúng âm thầm tích tụ cho đến khi xuất hiện đúng lúc gây đau đớn nhất:
Bài viết này giới thiệu một khung tự động hóa được xây dựng để giải quyết những thách thức này, đồng thời mang đến cho các Quản lý Kỹ thuật An ninh mạng có ý thức về rủi ro một cách để tận dụng AI trong quy trình tự động hóa của họ. Theo kinh nghiệm của chúng tôi, nhiều quản lý đã thận trọng đúng đắn khi làm điều này.
Chúng tôi xây dựng nó dựa trên ba khát vọng mà chúng tôi thường gặp khi làm việc với các SOC:
1. Giảm thời gian thu thập và tái sử dụng những gì đã hiệu quả lần trước.
Hiện tại, khi một sự cố được giải quyết, lý do đằng sau biện pháp khắc phục hiếm khi được ghi lại theo cách giúp ích cho lần tiếp theo. Các báo cáo hậu kỳ (post-mortems) được viết ra nhưng hầu như không bao giờ được đọc khi một sự cố tương tự xảy ra vài tháng sau. Và với tỷ lệ luân chuyển nhân viên phân tích từ 10–25% ở một nửa số SOC (1), kiến thức đó sẽ biến mất khi họ ra đi. Khung này sử dụng các pipeline Truy xuất Tăng cường Sinh (RAG) để tự động thu thập lý do đó và đưa nó trở lại trước mặt các nhà phân tích vào đúng thời điểm họ cần, mà không yêu cầu thêm bất kỳ nỗ lực nào từ phía họ.
2. Trả lại sự tập trung cho các nhà phân tích để làm công việc thực sự cần sự sáng tạo của con người.
Việc phải vật lộn với một danh sách kiểm tra hành chính trong lúc đang xử lý sự cố trực tiếp là thời điểm hoàn toàn sai để làm điều đó. Bằng cách loại bỏ các công việc thường nhật khỏi vai trò của nhà phân tích — như tìm kiếm trong các luồng Slack, đào bới các ghi chú giải quyết cũ — khung này giải phóng không gian tinh thần cho những quyết định mang tính phán đoán mà chỉ con người mới có thể đưa ra.
3. Làm cho AI an toàn để thực sự sử dụng trong các quy trình SOC thực tế.
Sự quan tâm là rõ ràng — các cuộc khảo sát liên tục báo cáo rằng 50–90% tổ chức đang "khám phá" hoặc "lên kế hoạch" sử dụng AI trong SOC (2). Phần khó là biến điều đó thành thứ mà các đội tin tưởng trong lúc xử lý sự cố trực tiếp, điều này thường xoay quanh một vài lo ngại:
Không có vấn đề nào trong số này hoàn toàn là kỹ thuật, nhưng một phần giải pháp nằm ở đó. Kho lưu trữ dưới đây được xây dựng xoay quanh điều đó: tự động hóa các công việc lặp đi lặp lại, không sáng tạo, giữ bối cảnh hữu ích gần gũi với nhà phân tích, và cho phép các đội điều chỉnh mức độ sử dụng AI lên hoặc xuống dựa trên mức chấp nhận rủi ro và nơi họ muốn có sự can thiệp của con người.
Quy trình nhận một tải trọng JSON tại một địa chỉ webhook được tạo trong n8n. Định dạng này điển hình cho một sự cố hoặc ticket từ SIEM (ví dụ: Elastic) hoặc công cụ ticketing (ví dụ: Jira) của bạn.
Tải trọng được tiếp nhận và kích hoạt ba truy xuất song song: tài liệu tham khảo phù hợp nhất gần
Dưới đây là bản dịch tiếng Việt cho đoạn văn bạn cung cấp:
---
sổ tay tham chiếu, các sự cố tương tự đã được giải quyết từ hồ sơ lịch sử của bạn và thông tin tình báo mối đe dọa hiện tại từ web.
Một tác nhân tổng hợp kết hợp cả ba nguồn và tạo ra một sổ tay vận hành có cấu trúc: các hành động ngay lập tức, các bước ngăn chặn, chỉ số IOC, các giả định được nêu rõ ràng và mức độ tin cậy khi độ chắc chắn thấp.
Nguyên tắc là tái sử dụng, không phải phát minh lại, mỗi lần và giải quyết các sự cố lặp lại nhanh hơn. Bạn đang yêu cầu LLM tổ chức những gì nhóm của bạn đã biết, chứ không phải tạo ra một kế hoạch phản hồi từ dữ liệu huấn luyện chung.
Nền tảng của việc này là một pipeline RAG, cũng được xây dựng bằng n8n, giúp phân đoạn các sổ tay và sự cố trong quá khứ của bạn và lưu trữ chúng trong cơ sở dữ liệu vector Supabase, sẵn sàng cho quy trình làm việc chính. Các hướng dẫn được cung cấp để liên tục tích hợp các ticket đã giải quyết mới hoặc sổ tay mới vào cơ sở dữ liệu vector này.
Hãy xem xét kỹ hơn từng luồng truy xuất:
**Truy xuất sự cố lịch sử.** Các sự cố đã giải quyết đi qua cùng một pipeline vector. Cùng một cơ sở dữ liệu, nhưng bảng khác nhau. Tìm kiếm tương tự sẽ kéo về các trường hợp trong quá khứ có liên quan nhất với đầy đủ ngữ cảnh: chuyện gì đã xảy ra, nó đã được ngăn chặn như thế nào, điều gì hiệu quả, điều gì mất nhiều thời gian hơn dự kiến.
Kết quả từ cả ba luồng được hợp nhất vào một tác nhân tổng hợp duy nhất. Tác nhân tổng hợp lấy khối thông tin đó cùng với dữ liệu sự cố ban đầu và tạo ra sổ tay vận hành.
LLM có thể cắm và chạy. Khi một mô hình mạnh hơn được phát hành, bạn chỉ cần thay đổi một giá trị cấu hình và phần còn lại của quy trình làm việc không bị ảnh hưởng. Đối với các nhóm không thể gửi dữ liệu sự cố đến một nhà cung cấp AI đám mây — đây là một ràng buộc thực tế trong nhiều môi trường doanh nghiệp — bất kỳ endpoint tương thích với OpenAI nào cũng có thể hoạt động như một giải pháp thay thế, bao gồm Ollama hoặc vLLM để suy luận hoàn toàn cục bộ. Quy trình làm việc không quan tâm mô hình sống ở đâu.
Pipeline nhập dữ liệu tách biệt với quy trình làm việc thời gian chạy. Bạn chạy nhập dữ liệu một lần để điền vào các bảng vector — sổ tay, sự cố đã giải quyết, sự cố thử nghiệm — và chỉ khi bạn muốn thêm các đoạn mới vào cơ sở dữ liệu trong tương lai. Quy trình làm việc thời gian chạy không bao giờ chạm vào nó.
Quy trình làm việc tạo ra hai đầu ra cùng lúc. Nếu bạn có một định dạng đầu ra mong muốn, bạn có thể loại bỏ một đầu ra để tiết kiệm chi phí token đầu ra của LLM.
Cả hai đều đến từ cùng một lần chạy tổng hợp. JSON là đầu ra có thẩm quyền; markdown được tạo ra từ nó. Nếu bạn chỉ cần phiên bản có thể đọc được cho con người, hãy bỏ qua JSON. Nếu bạn đang xây dựng một tích hợp, hãy phân tích cú pháp các trường có cấu trúc và bỏ qua markdown.
Trước khi chạy quy trình làm việc trên dữ liệu thực, ba điều cần phải ở trạng thái hợp lý.
**Sổ tay tham khảo.** Ít nhất là cho các sự cố có khối lượng lớn nhất mà tổ chức của bạn phải đối mặt. Chúng không cần phải dài — một sổ tay bao gồm tiêu chí phát hiện, các bước sơ cứu ban đầu, các tùy chọn ngăn chặn và các mẫu dương tính giả đã biết là đủ. Chất lượng truy xuất tỷ lệ thuận với tính cụ thể. Một sổ tay "phản ứng với phần mềm độc hại" chung chung sẽ trả về hướng dẫn chung chung. Một sổ tay được viết cho các phát hiện ransomware của EDR của bạn sẽ trả về thứ gì đó có thể sử dụng được.
**Lịch sử sự cố đã giải quyết.** Luồng truy xuất lịch sử cần các bản ghi với một
nội dung thực tế trong lĩnh vực khắc phục sự cố và bài học kinh nghiệm. Các mục nhập theo mẫu có sẵn chỉ gây nhiễu. Những bản ghi mô tả chính xác điều gì đã xảy ra, hệ thống nào liên quan và giải pháp thực tế là gì mới là yếu tố cải thiện chất lượng đầu ra. Quy trình làm việc sẽ trở nên hữu ích hơn theo thời gian khi lịch sử dữ liệu phát triển.
Ánh xạ MITRE ATT&CK trên các ticket của bạn. Không bắt buộc tuyệt đối, nhưng pipeline tiếp nhận sử dụng các trường tactic và technique để làm giàu kết quả truy xuất. Hiện đã có một quy trình làm việc n8n MITRE Mapping đi kèm có thể thực hiện việc này cho bạn.
Một số nhóm vận hành trước tiên chạy tính năng nhóm AI của SIEM — kết hợp các cảnh báo liên quan thành một ticket tổng hợp duy nhất — và chuyển sự cố tổng hợp đó vào. Đây là một mẫu được hỗ trợ và mang lại kết quả truy xuất tốt hơn so với đầu vào là các cảnh báo đơn lẻ thô.
Một trong những tác dụng phụ đáng mong đợi khi triển khai hệ thống này là nó sẽ hướng dẫn bạn nâng cấp tư thế bảo mật của tổ chức.
Prompt tổng hợp (synthesizer prompt) thực thi việc ghi nguồn rõ ràng. Mọi khuyến nghị trong runbook đều mang một nhãn:
Điểm thứ tư có thể cần giải thích. Agent không được hướng dẫn để loại bỏ kiến thức chung có thể làm giảm tính hữu ích của đầu ra. Nó được hướng dẫn để gắn nhãn một cách trung thực. Người đọc sẽ biết đâu là tiền lệ của tổ chức và đâu là thông tin do mô hình điền vào.
Ngoài ra còn có xử lý trường hợp không khớp rõ ràng. Nếu không có sự cố lịch sử nào khớp đủ gần, runbook sẽ nói rõ điều đó. Nó không tạo ra hướng dẫn có độ tin cậy cao từ một bảng trống và bỏ qua thực tế đó.
Trước khi ghi vào cơ sở dữ liệu, đầu ra sẽ trải qua quá trình xác thực schema có cấu trúc. Các khóa bắt buộc phải có mặt và không null. Schema thất bại → thông báo lỗi. Không có ghi âm thầm các runbook bị lỗi.
Cách dễ nhất để kiểm tra điều này là sử dụng giao diện người dùng mà chúng tôi đã xây dựng: https://incident-response.deployed.engineer. Công cụ này cho phép bạn gửi payload JSON đến quy trình làm việc (mà chúng tôi đã lưu trữ trên n8n cloud). Có chi phí LLM cho mỗi yêu cầu, vì vậy chúng tôi yêu cầu bạn lấy một khóa từ OpenRouter để sử dụng cho các cuộc gọi LLM. Mỗi lần chạy sẽ tốn một đô la hoặc
