Trí tuệ nhân tạo (AI) đang nhanh chóng được ứng dụng vào các hoạt động bảo mật, nhưng nhiều chuyên gia vẫn đang gặp khó khăn trong việc biến các thử nghiệm ban đầu thành giá trị vận hành nhất quán. Điều này là do các SOC đang áp dụng AI mà không có phương pháp tiếp cận có chủ đích để tích hợp vào hoạt động. Một số nhóm coi AI là một lối tắt cho các quy trình bị lỗi. Những nhóm khác lại cố gắng áp dụng machine learning cho các vấn đề chưa được xác định rõ ràng.
Kết quả từ Khảo sát SOC SANS 2025 của chúng tôi củng cố sự mất kết nối đó. Một phần đáng kể các tổ chức đã thử nghiệm AI, nhưng 40% các SOC sử dụng công cụ AI hoặc ML mà không định nghĩa chúng là một phần của hoạt động, và 42% dựa vào các công cụ AI/ML "out of the box" mà không hề tùy chỉnh. Kết quả là một mô hình quen thuộc. AI có mặt trong SOC nhưng chưa được vận hành hóa. Các nhà phân tích sử dụng nó một cách không chính thức, thường với độ tin cậy không đồng đều, trong khi lãnh đạo vẫn chưa thiết lập một mô hình nhất quán về vị trí của AI, cách xác thực đầu ra của nó, hoặc quy trình làm việc nào đủ trưởng thành để hưởng lợi từ việc tăng cường.
AI thực sự có thể cải thiện năng lực, sự trưởng thành, khả năng lặp lại quy trình, cũng như năng suất và sự hài lòng của nhân viên SOC. Nó chỉ hoạt động hiệu quả khi các nhóm thu hẹp phạm vi vấn đề, xác thực logic của họ và xử lý đầu ra với sự nghiêm ngặt như họ mong đợi từ bất kỳ nỗ lực kỹ thuật nào. Cơ hội không nằm ở việc tạo ra các loại công việc mới, mà ở việc tinh chỉnh những cái đã có và cho phép thử nghiệm, phát triển để mở rộng các khả năng hiện có. Khi AI được áp dụng cho một nhiệm vụ cụ thể, có giới hạn rõ ràng và đi kèm với một quy trình xem xét rõ ràng, tác động của nó sẽ trở nên dễ dự đoán và hữu ích hơn.
Dưới đây là năm lĩnh vực mà AI có thể cung cấp hỗ trợ đáng tin cậy cho SOC của bạn.
1. Detection Engineering
Detection engineering về cơ bản là xây dựng một cảnh báo chất lượng cao có thể được đưa vào SIEM, một đường dẫn MDR hoặc một hệ thống vận hành khác. Để khả thi, logic cần được phát triển, thử nghiệm, tinh chỉnh và vận hành với mức độ tin cậy không để lại nhiều chỗ cho sự mơ hồ. Đây là nơi AI có xu hướng được áp dụng không hiệu quả.
Trừ khi đó là kết quả mục tiêu, đừng cho rằng AI sẽ khắc phục các thiếu sót trong DevSecOps hoặc giải quyết các vấn đề trong đường dẫn cảnh báo. AI có thể hữu ích khi được áp dụng cho một vấn đề được xác định rõ ràng, có thể hỗ trợ xác thực và tinh chỉnh hoạt động liên tục. Một ví dụ rõ ràng từ khóa học SANS SEC595: Applied Data Science and AI/ML for Cybersecurity là một bài tập machine learning kiểm tra tám byte đầu tiên của luồng gói tin để xác định xem lưu lượng có được tái tạo thành DNS hay không. Nếu việc tái tạo không khớp với bất cứ điều gì đã thấy trước đây cho DNS, hệ thống sẽ đưa ra cảnh báo độ tin cậy cao. Giá trị đến từ độ chính xác của nhiệm vụ và chất lượng của quá trình đào tạo, chứ không phải từ tự động hóa rộng rãi. Việc triển khai dự kiến là kiểm tra tất cả các luồng trên UDP/53 (và TCP/53) và đánh giá tổn thất tái tạo từ một autoencoder được tinh chỉnh bằng machine learning. Các luồng vi phạm ngưỡng được gắn cờ là bất thường.
Ví dụ chi tiết này minh họa một phát hiện được thiết kế bằng AI, có thể triển khai được. Bằng cách kiểm tra tám byte đầu tiên của luồng gói tin và kiểm tra xem chúng có tái tạo thành DNS dựa trên các mẫu đã học trong lưu lượng truy cập lịch sử hay không, chúng ta tạo ra một vấn đề phân loại rõ ràng, có thể kiểm tra được. Khi các byte đó không khớp với những gì DNS thường trông như thế nào, hệ thống sẽ cảnh báo. AI giúp ích ở đây vì phạm vi hẹp và tiêu chí đánh giá khách quan. Nó có thể hiệu quả hơn một phát hiện dựa trên heuristic, theo quy tắc vì nó học cách mã hóa/giải mã những gì quen thuộc. Những thứ không quen thuộc (trong trường hợp này là DNS) không thể được mã hóa/giải mã đúng cách. Những gì AI không thể làm là khắc phục các vấn đề cảnh báo được xác định mơ hồ hoặc bù đắp cho một thiếu sót trong kỷ luật kỹ thuật.
2. Threat Hunting
Threat hunting thường được miêu tả là nơi AI có thể "khám phá" các mối đe dọa một cách tự động, nhưng điều đó bỏ qua mục đích của quy trình làm việc này. Hunting không phải là detection engineering sản xuất. Nó phải là một khả năng nghiên cứu và phát triển của SOC, nơi các nhà phân tích khám phá ý tưởng, kiểm tra các giả định và đánh giá các tín hiệu chưa đủ mạnh để trở thành một phát hiện được vận hành. Điều này là cần thiết vì bối cảnh lỗ hổng và mối đe dọa đang thay đổi nhanh chóng, và các hoạt động bảo mật phải liên tục thích ứng với sự biến động và không chắc chắn của vũ trụ đảm bảo thông tin.
AI phù hợp ở đây vì công việc mang tính thăm dò. Các nhà phân tích có thể sử dụng nó để thử nghiệm một cách tiếp cận, so sánh các mẫu hoặc kiểm tra xem một giả thuyết có đáng để điều tra hay không. Nó giúp tăng tốc các giai đoạn đầu của phân tích, nhưng nó không quyết định điều gì là quan trọng. Mô hình là một công cụ hữu ích, không phải là cơ quan có thẩm quyền cuối cùng.
Hunting cũng trực tiếp cung cấp thông tin cho detection engineering. AI có thể giúp tạo ra logic ứng viên hoặc làm nổi bật các mẫu bất thường, nhưng các nhà phân tích vẫn chịu trách nhiệm giải thích môi trường và quyết định ý nghĩa của một tín hiệu. Nếu họ không thể đánh giá đầu ra của AI hoặc giải thích tại sao điều gì đó quan trọng, cuộc săn có thể không mang lại điều gì hữu ích. Lợi ích của AI ở đây là ở tốc độ và phạm vi thăm dò hơn là sự chắc chắn hoặc phán đoán. Chúng tôi cảnh báo bạn nên sử dụng operational security (OpSec) và bảo vệ thông tin. Vui lòng chỉ cung cấp thông tin liên quan đến hunting cho các hệ thống được ủy quyền, AI hoặc các hệ thống khác.
3. Software Development and Analysis
Các SOC hiện đại hoạt động dựa trên mã. Các nhà phân tích viết Python để tự động hóa điều tra, xây dựng công cụ PowerShell để thẩm vấn host và tạo các truy vấn SIEM phù hợp với môi trường của họ. Nhu cầu lập trình liên tục này khiến AI trở thành một sự phù hợp tự nhiên cho software development and analysis. Nó có thể tạo ra mã nháp, tinh chỉnh các đoạn mã hiện có hoặc tăng tốc việc xây dựng logic mà trước đây các nhà phân tích phải tự tay thực hiện.
Tuy nhiên, AI không hiểu vấn đề cơ bản. Các nhà phân tích phải diễn giải và xác thực mọi thứ mà mô hình tạo ra. Nếu một nhà phân tích thiếu kiến thức chuyên sâu trong một lĩnh vực, đầu ra của AI có thể nghe có vẻ đúng ngay cả khi nó sai, và nhà phân tích có thể không có cách nào để nhận ra sự khác biệt. Điều này tạo ra một rủi ro duy nhất: các nhà phân tích có thể triển khai hoặc dựa vào mã mà họ không hiểu đầy đủ và chưa được kiểm tra đầy đủ.
AI hiệu quả nhất ở đây khi nó giảm bớt chi phí vận hành cơ học. Nó giúp các nhóm đạt được điểm khởi đầu có thể sử dụng nhanh hơn. Nó hỗ trợ tạo mã trong Python, PowerShell hoặc các ngôn ngữ truy vấn SIEM. Nhưng trách nhiệm về tính đúng đắn vẫn thuộc về con người, những người hiểu hệ thống, dữ liệu và hậu quả hoạt động của việc chạy mã đó trong môi trường sản xuất.
Tác giả gợi ý rằng nhóm nên phát triển các hướng dẫn về style phù hợp cho mã và chỉ sử dụng các thư viện và package được ủy quyền (nghĩa là đã được kiểm tra và phê duyệt). Bao gồm các hướng dẫn và yêu cầu phụ thuộc như một phần của mỗi lời nhắc, hoặc sử dụng một công cụ phát triển AI/ML cho phép cấu hình các thông số kỹ thuật này.
4. Automation and Orchestration
Tự động hóa từ lâu đã là một phần của các hoạt động SOC, nhưng AI đang định hình lại cách các nhóm thiết kế các quy trình làm việc này. Thay vì tự động ghép nối các chuỗi hành động hoặc dịch các runbook thành logic tự động hóa, các nhà phân tích giờ đây có thể sử dụng AI để phác thảo cấu trúc. AI có thể phác thảo các bước, đề xuất logic phân nhánh và thậm chí chuyển đổi mô tả ngôn ngữ tự nhiên thành định dạng có cấu trúc mà các nền tảng orchestration yêu cầu.
Tuy nhiên, AI không thể quyết định khi nào tự động hóa nên chạy. Câu hỏi trung tâm trong orchestration vẫn không thay đổi: hành động tự động nên thực thi ngay lập tức, hay nên trình bày thông tin cho nhà phân tích xem xét trước? Lựa chọn đó phụ thuộc vào mức độ chấp nhận rủi ro của tổ chức, độ nhạy cảm của môi trường và hành động cụ thể đang được xem xét.
Cho dù nền tảng là SOAR, MCP hay bất kỳ hệ thống orchestration nào khác, trách nhiệm khởi xướng một hành động phải thuộc về con người, không phải mô hình. AI có thể giúp xây dựng và tinh chỉnh quy trình làm việc, nhưng nó không bao giờ nên là cơ quan có thẩm quyền kích hoạt nó. Các ranh giới rõ ràng giúp tự động hóa có thể dự đoán được, giải thích được và phù hợp với tư thế rủi ro của SOC.
Sẽ có một ngưỡng mà mức độ thoải mái của tổ chức với các tự động hóa cho phép hành động nhanh chóng được thực hiện một cách tự động. Mức độ thoải mái đó đến từ việc kiểm tra rộng rãi và mọi người phản hồi các hành động được thực hiện bởi hệ thống tự động hóa một cách kịp thời.
5. Reporting and Communication
Reporting là một trong những thách thức dai dẳng nhất trong các hoạt động bảo mật, không phải vì các nhóm thiếu kỹ năng kỹ thuật mà vì việc chuyển đổi kỹ năng đó thành giao tiếp rõ ràng, có thể hành động rất khó mở rộng quy mô. Khảo sát SOC SANS 2025 chỉ ra rằng lĩnh vực này vẫn còn tụt hậu đến mức nào: 69% các SOC vẫn dựa vào các quy trình thủ công hoặc chủ yếu thủ công để báo cáo metrics. Khoảng cách này rất quan trọng. Khi báo cáo không nhất quán, lãnh đạo mất khả năng hiển thị, ngữ cảnh bị làm loãng và các quyết định hoạt động chậm lại.
AI cung cấp một cách tức thời và rủi ro thấp để nâng cao hiệu suất reporting của SOC. Nó có thể làm mượt mà các phần cơ học của việc báo cáo bằng cách chuẩn hóa cấu trúc, cải thiện sự rõ ràng và giúp các nhà phân tích chuyển từ ghi chú thô sang các bản tóm tắt được định dạng tốt. Thay vì mỗi nhà phân tích viết theo một phong cách khác nhau hoặc che giấu thông tin quan trọng trong chi tiết kỹ thuật, AI giúp tạo ra các đầu ra nhất quán, dễ đọc mà lãnh đạo có thể diễn giải nhanh chóng. Việc bao gồm moving averages, các giới hạn độ lệch chuẩn và làm nổi bật sự nhất quán tổng thể của SOC là một câu chuyện đáng để kể cho ban quản lý của bạn.
Giá trị không nằm ở việc làm cho các báo cáo nghe có vẻ bóng bẩy. Nó nằm ở việc làm cho chúng có tính mạch lạc và có thể so sánh được. Khi mọi bản tóm tắt sự cố, tổng hợp hàng tuần hoặc báo cáo metrics tuân theo một cấu trúc có thể dự đoán được, các nhà lãnh đạo có thể nhận ra xu hướng nhanh hơn và ưu tiên hiệu quả hơn. Các nhà phân tích cũng tiết kiệm được thời gian mà họ đã dành để vật lộn với cách diễn đạt, định dạng hoặc các giải thích lặp đi lặp lại.
Bạn là người Tiếp nhận, Định hình hay Sáng tạo? Hãy cùng thảo luận tại SANS Security Central 2026
Khi các nhóm bắt đầu thử nghiệm AI trong các quy trình làm việc này, điều quan trọng là phải nhận ra rằng không có một con đường duy nhất để áp dụng. Việc sử dụng AI trong SOC có thể được mô tả qua ba loại tiện lợi. Một taker sử dụng các công cụ AI như được cung cấp. Một shaper điều chỉnh hoặc tùy chỉnh các công cụ đó để phù hợp với quy trình làm việc. Một maker xây dựng một cái gì đó mới, chẳng hạn như ví dụ về phát hiện machine learning có phạm vi chặt chẽ đã được mô tả trước đó.
Tất cả các trường hợp sử dụng ví dụ này có thể thuộc một hoặc nhiều loại. Bạn có thể vừa là taker vừa là maker trong detection engineering, triển khai các quy tắc AI từ nhà cung cấp SIEM của bạn, cũng như tạo ra các phát hiện của riêng bạn. Hầu hết các nhóm là các maker thủ công cũng như taker (chỉ sử dụng các báo cáo hệ thống ticketing có sẵn) trong reporting. Bạn có thể là shaper trong automation, tùy chỉnh một phần các SOAR runbook do nhà cung cấp cung cấp. Hy vọng rằng, bạn ít nhất đang sử dụng các IOC-driven hunts do nhà cung cấp cung cấp; đó là điều mà mọi SOC cần làm. Việc khao khát hunting được thúc đẩy nội bộ sẽ đưa bạn vào danh mục maker đó.
Điều quan trọng là mỗi quy trình làm việc đều có những kỳ vọng rõ ràng về nơi AI có thể được sử dụng, cách xác thực đầu ra, rằng các bản cập nhật được thực hiện liên tục và cuối cùng các nhà phân tích vẫn chịu trách nhiệm bảo vệ các hệ thống thông tin.
Tôi sẽ khám phá những chủ đề này sâu hơn trong phiên phát biểu chính của mình tại SANS Security Central 2026 ở New Orleans. Bạn sẽ học cách đánh giá vị trí SOC của mình hiện nay và thiết kế một mô hình áp dụng AI giúp tăng cường chuyên môn của nhóm bạn. Tôi hy vọng sẽ gặp bạn ở đó!
Đăng ký SANS Security Central 2026 tại đây.
Lưu ý: Bài viết này được viết chuyên nghiệp và đóng góp bởi Christopher Crowley, SANS Senior Instructor.
