Purple Team của bạn không thực sự là Purple — Đó chỉ là Red và Blue đang ngồi chung một phòng

Việc bảo vệ mạng lưới vào lúc 2 giờ sáng thường diễn ra như thế này: một nhà phân tích copy-paste mã hash từ tệp PDF vào truy vấn SIEM. Một tập lệnh của Red Team đang được viết lại thủ công để Blue Team có thể sử dụng. Một bản vá đang chờ phê duyệt thay đổi trong một khoảng thời gian dài hơn cả cửa sổ khai thác lỗ hổng.

Không ai trong chuỗi đó kém cỏi cả. Mọi người đều đang làm đúng công việc của mình. Vấn đề nằm ở hệ thống, quy trình làm việc và những khâu bàn giao hỗn loạn.

Ngược lại, "đồng hồ" của kẻ tấn công gần như đã biến mất.

Vào năm 2024, thời gian trung bình từ khi một CVE được công bố đến khi có bản exploit hoạt động là 56 ngày. Đến năm 2025, con số này đã giảm xuống còn 23 ngày. Tính đến thời điểm hiện tại của năm 2026, thời gian này chỉ còn khoảng 10 giờ, dựa trên 3.532 cặp CVE-exploit từ CISA KEV, VulnCheck KEV và ExploitDB.

Tin tốt là đồng hồ của bên phòng thủ đã tăng tốc lên mức tính bằng giờ. Nhưng tin thực sự xấu là đồng hồ của kẻ tấn công đã vượt xa và hiện đang chạy bằng giây. Đây thậm chí không còn là một cuộc chiến công bằng.

Trong một thập kỷ qua, ngành bảo mật đã có một cái tên cho phương pháp giúp thu hẹp khoảng cách này: Purple Teaming. Đó là câu trả lời đúng đắn. Chỉ là nó chưa thực sự khả thi cho đến tận bây giờ.

Bản chất thực sự của Purple Teaming

Purple Teaming có khái niệm rất đơn giản.

Red Team tìm ra các con đường mà kẻ tấn công sẽ đi. Blue Team xác nhận liệu các biện pháp phát hiện có hoạt động và ngăn chặn có hiệu quả hay không. Họ lặp lại quy trình này. Đầu ra của Red Team trở thành đầu vào của Blue Team và ngược lại. Vòng lặp này thắt chặt tư thế an ninh của tổ chức một cách liên tục thay vì chỉ mỗi quý một lần.

Đó là ý tưởng, và nó rất vững chắc. Nhưng đáng buồn thay, khâu thực thi lại là nơi mọi thứ sụp đổ.

3 lý do khiến Purple Teaming truyền thống chưa thể đi vào vận hành thực tế

Lý do 1: Purple Teaming thủ công tạo ra quá nhiều rào cản

Hầu như không ai vận hành Purple Teaming như một vòng lặp thực thụ. Các nhóm không trao đổi đủ thường xuyên; và khi họ làm vậy, mọi người bị cuốn vào các cuộc họp kéo dài, các báo cáo chi tiết, các buổi hậu kiểm (post-mortem) lê thê. Nút thắt cổ chai hầu như luôn nằm ở con người.

Hãy nhìn vào nơi mà thời gian của bên phòng thủ thực sự tiêu tốn:

• Không phải bên trong EDR — nó đã cảnh báo.
• Không phải bên trong SIEM — nó đã tương quan dữ liệu.
• Không phải bên trong máy quét — nó đã có CVE.

Thời gian phản ứng bị lãng phí trong quá trình chuyển giao: Một tin nhắn Slack chưa đọc, một mã hash được copy-paste thủ công, một tệp PDF được gửi qua email để phê duyệt, một yêu cầu (ticket) chờ người xem xét. Đây chính là quy trình bàn giao chồng chéo (spaghetti handoff). Một khi bạn nhận ra những điểm kém hiệu quả này, bạn sẽ thấy chúng hiện hữu khắp nơi.

Lý do 2: Điều phối các nhóm và công cụ là nút thắt cổ chai thực sự

Nhóm mạng quản lý tường lửa. SOC xử lý cảnh báo. Red Team thực hiện diễn tập. Blue Team xây dựng các quy tắc phát hiện. Nhóm quản lý lỗ hổng (VM) theo dõi CVE. Nhóm vận hành IT áp dụng bản vá.

Mỗi nhóm vận hành một hoặc nhiều công cụ; mỗi công cụ tạo ra một sản phẩm (phát hiện, cảnh báo, báo cáo, ticket) được tiếp nhận, diễn giải lại và bàn giao. Những gì các nhóm này cùng nhau tạo ra đáng lẽ phải là một dịch vụ: một tư thế an ninh được xác thực liên tục. Nhưng thực tế, nó thường là một mớ hỗn độn được chắp vá bởi những con người đang kiệt sức vì phải nhập dữ liệu vào Jira lúc nửa đêm.

Vì vậy, Purple Teaming phần lớn vẫn chỉ là mục tiêu xa vời, một ý tưởng thú vị trong các bài thuyết trình của nhà cung cấp, hoặc có thể là một đợt diễn tập hàng quý, nhưng hầu như chưa bao giờ được đưa vào vận hành thực tế một cách hiệu quả.

Lý do 3: Purple Teaming truyền thống không thể theo kịp các đối thủ được hỗ trợ bởi AI

Đây là những gì đã thay đổi: Kẻ tấn công đã có LLM, còn bên phòng thủ vẫn đang mải mê điền yêu cầu trên Jira.

Đối với hầu hết các tổ chức, chỉ riêng quy trình phê duyệt thay đổi hiện đã dài hơn cả cửa sổ khai thác lỗ hổng.

Một kẻ tấn công được AI hỗ trợ có thể xâm nhập hệ thống trong 73 giây. Trong khi đó, một bên phòng thủ, làm việc qua chuỗi bàn giao tiêu chuẩn giữa SOC, Red Team, Blue Team và IT, thường mất ít nhất 24 giờ để triển khai một bản sửa lỗi.

Một cuộc diễn tập Purple Team hàng quý, hay thậm chí hàng tháng, không còn là một vòng lặp nữa. Nó chỉ là một việc cần làm để đối phó, một bức ảnh chụp nhanh của một trận chiến đã kết thúc từ lâu.

Sự xuất hiện của Autonomous Purple Teaming (Purple Teaming tự hành)

Chính công nghệ đang rút ngắn thời gian của kẻ tấn công cũng có thể giúp rút ngắn thời gian của bên phòng thủ.

Tin tốt là Autonomous Purple Teaming, về bản chất, chính xác là loại quy trình mà AI làm rất tốt: một vòng lặp chặt chẽ giữa hai chức năng chuyên biệt, nơi nút thắt cổ chai luôn là khâu bàn giao và chuyển giao kiến thức của con người.

Khi các tác nhân tự hành (Autonomous Agents) thực hiện việc bàn giao, vòng lặp cuối cùng sẽ khép lại với tốc độ của máy móc.

• Các phát hiện của Red Team tự động trở thành bài kiểm tra của Blue Team.
• Các lỗ hổng của Blue Team trở thành bài diễn tập tiếp theo của Red Team.
• Không cần nghỉ giải lao, không có gián đoạn bởi các sự kiện cá nhân hay ngày lễ.

Hệ thống mà mọi người đã mô tả trong mười năm qua giờ đây cuối cùng đã có thể chạy như một phương pháp luận liên tục, không phải là một sự kiện trên lịch.

Đây không phải là "AI cho bảo mật" theo cách mà hầu hết các nhà cung cấp quảng bá trong năm qua như: tạo quy tắc YARA, tóm tắt cảnh báo hay soạn bản nháp ticket. Đó chỉ là tự động hóa tác vụ. Chúng hữu ích nhưng chỉ mang tính chất bổ trợ. Quyền tự hành thực sự (True autonomy) là một thứ khác: một tác nhân chạy toàn bộ vòng lặp từ đầu đến cuối, với mọi bước đều có thể kiểm tra để bạn có thể can thiệp, điều chỉnh hoặc thu hồi.

Autonomous Purple Teaming trong thực tế: BAS, Pentest tự động và điều phối hỗ trợ bởi AI

Để hiệu quả, Autonomous Purple Teaming yêu cầu ba thành phần hoạt động như một hệ thống thống nhất:

Automated Penetration Testing (Kiểm thử xâm nhập tự động) là câu hỏi của Red Team được trả lời liên tục: liệu kẻ tấn công có thể tiếp cận các tài sản quan trọng nhất (crown jewels) trong môi trường của bạn, với các mức độ phơi nhiễm và kiểm soát hiện tại không?

Breach and Attack Simulation (BAS) (Mô phỏng vi phạm và tấn công) là câu trả lời của Blue Team: tường lửa có chặn được không, EDR có bắt được không, quy tắc SIEM có kích hoạt không, và phản ứng có diễn ra đúng như kịch bản (runbook) không?

Điều phối hỗ trợ bởi AI (AI-powered mobilization) là phần vốn trước đây là con người nhập liệu vào Jira, nay được vận hành bởi một chuỗi các tác nhân chuyên biệt. Một cảnh báo CISA xuất hiện. Một tác nhân CTI làm giàu dữ liệu (enrich) so với môi trường của bạn. Một tác nhân đánh giá quyết định mối đe dọa có liên quan và lấy dữ liệu tư thế hiện tại từ BAS, Pentest. Các tác nhân Red và Blue chạy mô phỏng và xác thực song song. Một tác nhân điều phối tự động triển khai các bản sửa lỗi ít rủi ro, mở ticket cho các bản sửa lỗi vừa phải và gắn cờ phần còn lại để con người xem xét.

Không có nhà phân tích nào trong chuỗi này. Mọi bước vẫn hiển thị trong bảng điều khiển vận hành. Không có "hộp đen", chỉ là không có con người phải ngồi gõ Jira.

Kết quả đầu ra không phải là 50.000 CVE được xếp hạng theo CVSS. Đó là một danh sách hành động liên tục giữa Red và Blue: những gì thực sự có thể bị khai thác hôm nay, dựa trên các biện pháp kiểm soát thực tế của bạn, và những gì cần làm trước khi cửa sổ khai thác đóng lại.

Đó mới là Purple Teaming thực thụ, không chỉ là tự động hóa. Đó là vòng lặp mà ngành bảo mật hằng mơ ước, cuối cùng đã vận hành theo tốc độ mà các mối đe dọa do AI tạo ra yêu cầu.

Chứng kiến hệ thống vận hành trong doanh nghiệp thực tế

Vòng lặp liên tục là câu trả lời đúng. Nhưng "liên tục" vẫn ngụ ý con người đang điều tiết nó. Khi kẻ tấn công hoạt động với tốc độ máy móc, khoảng cách quan trọng không phải là giữa việc nhìn thấy và phát hiện; đó là giữa phát hiện và chứng minh đủ nhanh để kẻ thù sử dụng AI không tìm ra trước.

Đây là nơi quá trình xác thực chuyển từ liên tục sang tự hành: Các tác nhân AI đọc cảnh báo, xác định phạm vi kiểm tra, chạy mô phỏng, đẩy bản sửa lỗi và viết báo cáo, trong khi SOC tập trung vào bức tranh lớn hơn.

Lưu ý: Bài viết này được viết bởi Sıla Özeren Hacıoğlu, Kỹ sư Nghiên cứu Bảo mật tại Picus Security.