SOC của bạn đã sẵn sàng cho AI Agents chưa? Kiểm tra mức độ trưởng thành trước khi triển khai

Theo khảo sát “State of AI in Security Operations 2026” của Prophet Security, 40% đội ngũ an ninh mạng hiện đang sử dụng AI hàng ngày, và 56% khác đang thử nghiệm. Chỉ 4% không có kế hoạch áp dụng công nghệ này. Đối với các đội ngũ đang trong giai đoạn thử nghiệm, câu hỏi lớn tiếp theo là liệu SOC của họ đã sẵn sàng để triển khai AI hay chưa.

Sự sẵn sàng của SOC đối với AI bao gồm hai khía cạnh: liệu SOC có đang đối mặt với những vấn đề mà AI SOC agent được thiết kế để giải quyết, và liệu nó có đủ quyền truy cập dữ liệu, ngữ cảnh, tiêu chuẩn bằng văn bản và quy tắc giám sát mà AI agent cần để điều tra cảnh báo một cách chính xác trong môi trường của mình. Một SOC không cần phải đạt mức độ trưởng thành cao để sẵn sàng. AI agent thường bắt đầu công việc ở lớp thấp nhất – xử lý cảnh báo – và thời gian mà chúng tiết kiệm được cho các nhà phân tích sẽ tạo điều kiện để đội ngũ tập trung vào các lớp cao hơn.

Phần tiếp theo sẽ mô tả chi tiết những vấn đề này. Sự sẵn sàng về kỹ thuật bao gồm bốn lĩnh vực: quyền truy cập và ngữ cảnh, một tiêu chuẩn điều tra với các số liệu cơ bản, các quy tắc về những gì agent được phép làm, và một kế hoạch sử dụng thời gian tiết kiệm được.

Những SOC nào hưởng lợi nhiều nhất từ AI SOC agents?

Các SOC hưởng lợi nhiều nhất từ AI SOC agent thường nhận ra một số vấn đề dưới đây, cho dù nhà cung cấp bên ngoài xử lý cảnh báo hay các nhà phân tích nội bộ thực hiện.

Nếu MDR hoặc MSSP xử lý cảnh báo của bạn:

• MDR của bạn gắn cờ mối đe dọa quá chậm. Nhà cung cấp xử lý cảnh báo của bạn trong một hàng đợi chung với các khách hàng khác, vì vậy việc leo thang cho một cuộc xâm nhập thực sự có thể đến muộn hàng giờ sau khi hoạt động bắt đầu.
• MDR của bạn trả lại cảnh báo vì thiếu ngữ cảnh. Một cảnh báo leo thang đến với một bản tóm tắt ngắn gọn và các câu hỏi như liệu đăng nhập này có được mong đợi không, đây có phải là production server không, hay người dùng này có đang đi công tác không? Nhà cung cấp thường không hiểu rõ người dùng, tài sản và hoạt động kinh doanh của bạn để hoàn thành điều tra, vì vậy các nhà phân tích của bạn phải làm phần còn lại.
• MDR của bạn đóng cảnh báo mà không hiển thị công việc đã làm. Khi nhà cung cấp đánh dấu một cảnh báo là lành tính, ghi chú có thể không nói rõ những gì đã được kiểm tra và cách họ đi đến kết luận đó, vì vậy đội ngũ của bạn hoặc phải tin tưởng hoặc phải tự chạy lại cuộc điều tra.
• Phạm vi bảo hiểm của MDR dừng lại ở các công cụ mà họ hỗ trợ. Nhiều hợp đồng chỉ bao gồm EDR và một danh sách các nguồn log cụ thể, vì vậy các cảnh báo từ mọi thứ khác, chẳng hạn như một ứng dụng SaaS hoặc một nền tảng cloud thứ hai, sẽ rơi vào đội ngũ của bạn.

Nếu các nhà phân tích nội bộ của bạn xử lý hàng đợi, bao gồm cả những gì nhà cung cấp gửi lại:

• Câu hỏi “Chúng ta có bị ảnh hưởng không?” mất nhiều ngày để trả lời. Khi một vulnerability nghiêm trọng hoặc một chiến dịch mới xuất hiện trên tin tức, ban lãnh đạo muốn có câu trả lời ngay trong ngày. Để có được điều đó, cần phải săn lùng thủ công trên toàn bộ môi trường, thường do một nhà phân tích đang bận xử lý hàng đợi thực hiện.
• Các cảnh báo mức độ thấp hơn bị chờ đợi hoặc đóng hàng loạt. Một cuộc điều tra kỹ lưỡng đòi hỏi phải chuyển đổi giữa SIEM, EDR, identity provider, cloud console và các công cụ email, vì vậy đội ngũ chỉ tập trung vào các cảnh báo critical và high, và xử lý phần còn lại khi có thể. Trong khảo sát, 60% số người được hỏi cho biết một cảnh báo mà họ đã bỏ qua hoặc bỏ lỡ sau đó đã trở thành một vấn đề nghiêm trọng, chẳng hạn như một vụ breach hoặc downtime.
• Các phát hiện gây nhiễu bị tắt. Việc tinh chỉnh một rule thường xuyên kích hoạt quá nhiều cảnh báo mất thời gian mà đội ngũ không có, vì vậy rule đó bị vô hiệu hóa và kỹ thuật mà nó giám sát bị bỏ qua.
• Hunting và detection engineering phải chờ thời gian rảnh. Công việc chủ động chỉ được thực hiện khi có người có một buổi chiều rảnh rỗi, vì hàng đợi cảnh báo luôn được ưu tiên.
• Một vài nhà phân tích cấp cao phải gánh vác các trường hợp khó. Chỉ một hoặc hai người biết cách xử lý các cuộc điều tra khó khăn nhất, vì vậy một sự từ chức duy nhất có thể làm chậm trễ đội ngũ.
• Đêm và cuối tuần được bao phủ mỏng. Việc duy trì hàng đợi 24/7 đòi hỏi nhiều nhà phân tích hơn ngân sách cho phép, vì vậy các cảnh báo kích hoạt ngoài giờ làm việc phải chờ đến sáng hoặc chuyển cho người đang trực.

AI SOC agent được xây dựng cho công việc này. Chúng được thiết kế để bắt đầu xử lý từng cảnh báo ngay khi nó đến, bất kể công cụ nào đã tạo ra nó và vào bất kỳ giờ nào. Chúng có thể lấy ngữ cảnh mà nhà cung cấp bên ngoài thiếu từ các hệ thống của bạn và ghi lại bằng chứng đằng sau mỗi kết luận, để đội ngũ của bạn có thể kiểm tra. Một số còn có thể chạy một cuộc săn lùng ngay trong ngày một mối đe dọa mới được tiết lộ, biến câu hỏi “chúng ta có bị ảnh hưởng không?” thành một tập hợp các truy vấn có câu trả lời. Thời gian mà chúng tiết kiệm được cho các nhà phân tích có thể được dành cho công việc detection và hunting đang bị trì hoãn hiện nay.

Nếu một số vấn đề này nghe có vẻ quen thuộc, thì nhu cầu đã có. Câu hỏi tiếp theo là liệu SOC của bạn có thể hỗ trợ việc triển khai hay không.

AI agents phù hợp ở đâu trong mô hình trưởng thành của SOC?

Mô hình trưởng thành của SOC của Prophet Security, “SOC Hierarchy of Needs”, có năm cấp độ: quản lý cảnh báo (alert management), phạm vi phát hiện (detection coverage), nhận thức về mối đe dọa (threat awareness), săn lùng chủ động (proactive hunting) và cải thiện tư thế an ninh (posture improvements). Mỗi cấp độ phụ thuộc vào cấp độ bên dưới nó. Một đội ngũ bị chôn vùi trong cảnh báo hiếm khi có thời gian để săn lùng, và một đội ngũ săn lùng mà không có nhận thức về mối đe dọa thì không có ý tưởng rõ ràng về những gì cần tìm.

Nhiều SOC vẫn chưa ổn định được cấp độ đầu tiên. Trong khảo sát “State of AI in Security Operations 2026”, những người được hỏi cho biết 28% cảnh báo của họ không bao giờ được điều tra.

AI SOC agent thường bắt đầu ở cấp độ đầu tiên đó, điều tra các cảnh báo khi chúng đến. Các nền tảng mới hơn cũng chạy các cuộc săn lùng và đề xuất các phát hiện, công việc này vươn tới cấp độ hai và bốn. Dù bằng cách nào, thời gian mà chúng tiết kiệm được cho các nhà phân tích sẽ được dành cho công việc ở các cấp độ cao hơn cấp độ đầu tiên, vì vậy sự sẵn sàng phụ thuộc vào những gì cấp độ đầu tiên cần.

Một AI agent chỉ có thể điều tra những gì nó có thể truy vấn

Một AI agent điều tra bằng cách chạy các truy vấn đối với các công cụ của bạn, vì vậy nó không thể nhìn thấy bất cứ điều gì mà nó không có quyền truy cập. Nếu nó có thể truy vấn EDR nhưng không phải identity provider, nó có thể mô tả những gì đã xảy ra trên endpoint nhưng không thể biết tài khoản nào đứng đằng sau.

Sự sẵn sàng ở đây có ba phần:

• Truy cập API vào các nguồn mà một cuộc điều tra cần. Điều đó thường có nghĩa là SIEM, EDR, identity provider, các nền tảng cloud, email và các ứng dụng SaaS quan trọng.
• Ngữ cảnh mà agent có thể đọc. Một agent cần thông tin về mức độ quan trọng của tài sản (asset criticality), vai trò người dùng (user roles), danh sách VIP, các đơn vị kinh doanh và hoạt động lành tính đã biết, chẳng hạn như các bản quét theo lịch trình và script quản trị, để phân biệt kẻ tấn công với một quản trị viên hợp pháp.
• Đường dẫn dữ liệu lành mạnh (Healthy data pipelines). Một nguồn log im lặng hoặc bị trì hoãn có thể làm cho một cuộc điều tra trông có vẻ hoàn chỉnh trong khi bằng chứng quan trọng bị thiếu, vì vậy tình trạng của các đường dẫn cung cấp dữ liệu cho các cuộc điều tra cần được giám sát.

Một thử nghiệm nhanh: lấy năm sự cố gần đây và liệt kê mọi truy vấn mà một nhà phân tích cấp cao đã chạy để đóng chúng. Bất kỳ truy vấn nào mà agent không thể chạy đều đánh dấu một khoảng trống cần được khắc phục trước khi thử nghiệm.

Truy cập dữ liệu cũng đặt ra sự phản đối phổ biến nhất. Trong khảo sát của chúng tôi, 44% đội ngũ đã nêu ra vấn đề quyền riêng tư dữ liệu và cách các mô hình AI được đào tạo, đây là rào cản thường xuyên nhất mà những người được hỏi đã nêu tên. Hãy hỏi từng nhà cung cấp liệu dữ liệu của bạn có được sử dụng để đào tạo mô hình của họ hay không và dữ liệu của bạn được xử lý ở đâu.

Xác định một cuộc điều tra hoàn chỉnh và ghi lại số liệu cơ bản của bạn

Một dự án thử nghiệm cần một tiêu chuẩn bằng văn bản để đánh giá agent. Trong nhiều SOC, chỉ các nhà phân tích cấp cao mới biết tiêu chuẩn đó, và nó hiếm khi được ghi lại.

Tiêu chuẩn này bao gồm những bằng chứng nào để đóng một trường hợp phishing, khi nào một cảnh báo impossible-travel cần gọi cho quản lý của người dùng, và những gì được coi là đủ để gọi một cảnh báo là lành tính. Việc ghi lại nó cho các loại cảnh báo có khối lượng lớn nhất của bạn cũng cung cấp một tài liệu hướng dẫn cho các nhà phân tích mới.

Cũng nên giữ một danh sách các phát hiện đã bị tắt. Trong khảo sát của chúng tôi, có tới 40% tổ chức đã tắt một số phát hiện vì họ thiếu nhân lực để kiểm tra chúng. Khi một agent điều tra mọi cảnh báo, một số quy tắc đó có thể được bật lại, và danh sách này cho bạn biết nên bắt đầu từ đâu.

Sau đó, ghi lại các số liệu bạn sẽ so sánh: tỷ lệ cảnh báo được điều tra, thời gian trung bình để điều tra (mean time to investigate), thời gian từ cảnh báo đến lần xem xét đầu tiên, và tần suất các cảnh báo đã đóng được mở lại. Khảo sát cung cấp một điểm tham chiếu. Một cuộc điều tra kỹ lưỡng mất trung bình 75 phút, và các cảnh báo thường phải chờ gần một giờ trước khi có người mở chúng.

Quyết định những gì agent được phép làm, và ai phê duyệt thêm

Điều tra và hành động mang lại những rủi ro khác nhau, và hầu hết các đội ngũ xử lý chúng khác nhau. Trong khảo sát, 57% đội ngũ yêu cầu con người xem xét mọi quyết định của AI trước khi một cảnh báo được đóng. Về phản ứng, 44% để AI đề xuất các hành động mà con người thực hiện, 30% cho phép nó tự xử lý các biện pháp khắc phục rủi ro thấp, và không có người được hỏi nào cho phép nó tự chủ hoàn toàn, không giám sát.

Một SOC sẵn sàng có các quy tắc này được ghi lại trước khi bắt đầu thử nghiệm:

• Phê duyệt mặc định. Một danh sách các hành động vẫn cần con người phê duyệt, chẳng hạn như cô lập một host, vô hiệu hóa một tài khoản hoặc chặn một domain.
• Cách mở rộng quyền hạn. Ai có thể cấp cho agent quyền tự chủ hơn cho một loại hành động, và họ cần thấy hồ sơ theo dõi nào trước tiên.
• Nơi các phát hiện được lưu trữ. Các phát hiện của agent nên xuất hiện trong các công cụ quản lý trường hợp hoặc ticketing mà các nhà phân tích đã sử dụng, để không ai phải theo dõi một console khác.
• Ai chịu trách nhiệm phản hồi. Một người được chỉ định xem xét các lỗi của agent và biến các chỉnh sửa thành hướng dẫn mà nó sẽ sử dụng lần sau.

Bắt đầu với quyền truy cập chỉ đọc cho các cuộc điều tra, sau đó mở rộng quyền hạn khi niềm tin tăng lên, áp dụng các quy tắc tương tự mà một SOC sử dụng cho một nhà phân tích mới.

Danh sách kiểm tra sự sẵn sàng được ánh xạ tới mô hình trưởng thành

Trả lời mỗi câu hỏi có hoặc không. Phần 1 kiểm tra nhu cầu, và Phần 2 kiểm tra sự sẵn sàng về kỹ thuật. Cấp độ trong ngoặc đơn cho thấy mỗi mục thuộc lớp nào trong SOC Hierarchy of Needs.

Phần 1: SOC của bạn có cần AI SOC agents không?

• Các cảnh báo leo thang từ MDR hoặc MSSP của bạn có đến muộn hàng giờ sau khi hoạt động bắt đầu không? (Cấp độ 1: alert management)
• Nhà cung cấp của bạn có trả lại cảnh báo vì thiếu ngữ cảnh để hoàn thành chúng không? (Cấp độ 3: threat awareness)
• Nhà cung cấp của bạn có đóng cảnh báo mà không hiển thị những gì đã kiểm tra không? (Cấp độ 1: alert management)
• Các cảnh báo từ các công cụ ngoài phạm vi bảo hiểm của nhà cung cấp của bạn có rơi vào đội ngũ của bạn không? (Cấp độ 1: alert management)
• Có mất hơn một ngày để cho ban lãnh đạo biết liệu bạn có bị ảnh hưởng bởi một vulnerability hoặc chiến dịch mới không? (Cấp độ 4: proactive hunting)
• Các cảnh báo mức độ thấp và trung bình có bị chờ đợi, hoặc bị đóng hàng loạt mà không có điều tra không? (Cấp độ 1: alert management)
• Các phát hiện gây nhiễu có bị tắt vì không ai có thời gian để tinh chỉnh chúng không? (Cấp độ 2: detection coverage)
• Hunting và detection engineering có phải chờ đến khi có người có thời gian rảnh không? (Cấp độ 4: proactive hunting)
• Chỉ một hoặc hai nhà phân tích cấp cao có biết cách xử lý các trường hợp khó nhất của bạn không? (Cấp độ 1: alert management)
• Các cảnh báo kích hoạt vào ban đêm hoặc cuối tuần có phải chờ đến sáng không? (Cấp độ 1: alert management)

Mỗi câu trả lời “có” là một vấn đề mà AI SOC agent có thể giải quyết, và càng nhiều câu trả lời “có”, thì càng có lý do mạnh mẽ để triển khai.

Phần 2: SOC của bạn đã sẵn sàng để triển khai chúng chưa?

• Một công cụ mới có thể truy vấn các nguồn SIEM, EDR, identity, cloud và email của bạn thông qua API không? (Cấp độ 1: alert management)
• Mức độ quan trọng của tài sản (asset criticality), vai trò người dùng (user roles) và hoạt động lành tính đã biết có được ghi lại ở đâu đó mà một hệ thống có thể đọc không? (Cấp độ 3: threat awareness)
• Có một tiêu chuẩn bằng văn bản cho những gì một cuộc điều tra hoàn chỉnh bao gồm, đối với các loại cảnh báo chiếm phần lớn khối lượng của bạn không? (Cấp độ 1: alert management)
• Bạn đã quyết định những hành động nào vẫn cần con người phê duyệt, và ai có thể mở rộng quyền hạn của agent không? (Cấp độ 1: alert management)
• Bạn có giám sát liệu các nguồn log mà các cuộc điều tra của bạn phụ thuộc vào có đang đến không? (Cấp độ 2: detection coverage)
• Bạn có biết tỷ lệ cảnh báo hiện tại được điều tra và thời gian trung bình để điều tra của bạn không? (Cấp độ 1: alert management)
• Bạn có giữ một danh sách các phát hiện đã bị tắt vì lý do năng lực không? (Cấp độ 2: detection coverage)
• Có một kế hoạch, với những người chịu trách nhiệm được chỉ định, cho thời gian nhà phân tích mà một agent sẽ tiết kiệm được, chẳng hạn như các cuộc săn lùng theo lịch trình hoặc công việc detection không? (Cấp độ 4: proactive hunting)

Một câu trả lời “không” cho bất kỳ câu hỏi nào trong bốn câu đầu tiên đáng để khắc phục trước khi thử nghiệm sản xuất. Bốn câu còn lại có thể được thực hiện trong quá trình thử nghiệm.

Bạn nên làm gì nếu câu trả lời là “chưa”?

Hầu hết các mục trong danh sách Phần 2 là công việc cấu hình và tài liệu: cấp thông tin xác thực API, xuất ngữ cảnh tài sản và người dùng, và ghi lại tiêu chuẩn điều tra. Một thứ tự khả thi:

• Đầu tiên, khắc phục các khoảng trống truy cập từ thử nghiệm năm sự cố, vì mọi bước sau đó đều phụ thuộc vào việc agent nhìn thấy dữ liệu.
• Viết các tiêu chuẩn điều tra cho các loại cảnh báo có khối lượng lớn nhất của bạn.
• Chạy agent song song với các nhà phân tích của bạn trong vài tuần. Ghi lại số liệu cơ bản trước khi nó bắt đầu, và coi mọi sự ghi đè của nhà phân tích là dữ liệu về nơi agent cần thêm ngữ cảnh.
• Mở rộng quyền hạn của agent từng loại hành động một, khi hồ sơ của nó hỗ trợ.

Một số đội ngũ chưa sẵn sàng cân nhắc việc tự xây dựng agent của riêng họ. Khảo sát cho thấy cần thận trọng: 72% người dùng AI đã thử xây dựng các công cụ AI nội bộ, và 46% các dự án đó đã bị bỏ dở, không bao giờ đạt đến sản xuất, hoặc được thay thế bằng một sản phẩm thương mại.

Xây dựng một prototype hoạt động chỉ là một phần nhỏ của công việc. Phần lớn công việc là kỹ thuật và bảo trì các tích hợp mất nhiều tuần để xây dựng nhưng lại bị hỏng khi nhà cung cấp thay đổi API; các giới hạn tốc độ cần được xử lý; các mô hình bị lỗi thời cứ sau sáu đến chín tháng buộc phải thực hiện một vòng đánh giá, bảo vệ và kiểm tra prompt injection đầy đủ; và các bản ghi kiểm toán giải thích lý do tại sao mỗi cảnh báo được đóng.

Nguồn tham khảo: The Hacker News