Điều gì sẽ xảy ra nếu ứng dụng AI của bạn làm rò rỉ dữ liệu nhạy cảm, tạo ra nội dung độc hại hoặc tiết lộ các hướng dẫn nội bộ – và không có công cụ bảo mật nào của bạn phát hiện ra điều đó? Đây không phải là một giả thuyết. Nó đang xảy ra ngay bây giờ và phơi bày những lỗ hổng nghiêm trọng trong cách chúng ta bảo mật các hệ thống AI hiện đại.

Khi các hệ thống AI như LLM, tác nhân hoặc ứng dụng do AI điều khiển đi vào sản xuất, nhiều nhóm bảo mật ban đầu chuyển sang các công cụ quen thuộc: Các giải pháp AST như SAST, SCA và danh sách kiểm tra tuân thủ. Nhưng những công cụ đó không được thiết kế cho hành vi độc đáo của AI. Không giống như các ứng dụng truyền thống, các mô hình AI không tuân theo logic mã có thể đoán trước được. Rủi ro của chúng xuất hiện một cách linh hoạt – bị ảnh hưởng bởi đầu vào của người dùng, ngữ cảnh và thăm dò đối kháng. Đó là lý do tại sao việc kiểm tra cách chúng hoạt động dưới áp lực thực tế là rất quan trọng.

Tại Sao Các Công Cụ AppSec Truyền Thống Không Đủ

AppSec ban đầu tập trung vào phân tích tĩnh – cho đến khi những kẻ tấn công chỉ ra rằng rủi ro thực sự thường nằm trong hành vi động. Với AI, sự khác biệt thậm chí còn rõ rệt hơn. Đây là các hệ thống xác suất, được đào tạo và các lỗ hổng của chúng không nằm trong mã – chúng xuất hiện trong quá trình tương tác.

Điều đó không có nghĩa là phân tích tĩnh không liên quan. Trên thực tế, thế hệ bảo mật gốc AI tiếp theo kết hợp các kỹ thuật động và tĩnh, mỗi kỹ thuật được điều chỉnh để phơi bày các mối đe dọa AI cụ thể. Điều _không_ hiệu quả là dựa vào các công cụ cũ không được xây dựng cho các rủi ro dành riêng cho AI như tấn công prompt, rò rỉ dữ liệu và ảo giác.

Red teaming là một trong những cách hiệu quả nhất để khám phá những lỗ hổng về hành vi này. Nó kiểm tra căng thẳng các hệ thống AI trong các tình huống đối kháng, tiết lộ các vấn đề chỉ xuất hiện tại thời điểm chạy. Nhưng đó không phải là mảnh ghép duy nhất – nó bổ sung cho những nỗ lực rộng lớn hơn để điều chỉnh phân tích tĩnh và động cho bối cảnh mối đe dọa độc đáo của AI.

Cách Các Nhóm Đang Giải Quyết Red Teaming AI Ngày Nay

Ngày nay, các nhóm đang vận hành red teaming AI theo ba cách chính:

1. Nền tảng SaaS tự động

Các giải pháp như Mend AI Red Teaming cung cấp khả năng kiểm tra liên tục, có thể mở rộng, tích hợp vào các quy trình CI/CD. Các nền tảng này mô phỏng một loạt các kỹ thuật tấn công, từ tấn công prompt và rò rỉ dữ liệu đến jailbreak và ảo giác, trên LLM, tác nhân AI và các ứng dụng do AI điều khiển rộng hơn. Chúng thường cung cấp:

• Thư viện tấn công được xác định trước và có thể tùy chỉnh
• Mô phỏng thời gian chạy của các mối đe dọa mới nổi
• Báo cáo có thể hành động cho các nhóm phát triển và bảo mật
• Đề xuất khắc phục tùy chọn

Bằng cách cho phép kiểm tra lặp lại, tự động như một phần của quy trình làm việc phát triển, các nền tảng này giúp các nhóm phát hiện ra các lỗ hổng trước khi chúng đến tay người dùng.

2. Khung nguồn mở

Các dự án như PyRIT của Microsoft cung cấp các bộ công cụ mô-đun cho các nhóm xây dựng cơ sở hạ tầng red teaming của riêng họ. Chúng cung cấp toàn quyền kiểm soát logic kiểm tra, mô phỏng mối đe dọa và tùy chỉnh – làm cho chúng trở nên hấp dẫn đối với các tổ chức lớn hơn có nguồn lực để đầu tư vào các khung bên trong, dài hạn.

Tuy nhiên, những giải pháp này đòi hỏi sự duy trì đáng kể: cập nhật mô hình mối đe dọa liên tục, điều chỉnh đầu vào và tích hợp đường ống. Chúng cung cấp sức mạnh và sự linh hoạt, nhưng đi kèm với chi phí vận hành cao hơn.

3. Dịch vụ tư vấn

Các công ty như CrowdStrike và Trail of Bits cung cấp các cam kết red teaming theo yêu cầu, thường tập trung vào các triển khai có rủi ro cao. Các dịch vụ này bao gồm thiết kế kịch bản đối kháng, thăm dò do chuyên gia lãnh đạo và đánh giá bảo mật sâu. 

Mặc dù rất hiệu quả, nhưng những cam kết này thường bị giới hạn về thời gian và tốn nhiều tài nguyên. Nếu không tích hợp liên tục vào quy trình làm việc phát triển, tác động của chúng có thể giảm dần theo thời gian trừ khi được kết hợp với việc theo dõi nội bộ.

Tại Sao Vẫn Còn Khó Khăn

Red teaming các hệ thống AI vẫn là một hoạt động đang phát triển và không có tiêu chuẩn toàn ngành cho việc “phủ sóng” tốt trông như thế nào. Các nhóm đang xây dựng sổ tay đó trong thời gian thực.

• Hành vi của mô hình là động: Đầu ra thay đổi theo cách diễn đạt đầu vào, lịch sử người dùng và ngữ cảnh hệ thống, làm cho các số liệu pass/fail truyền thống kém hiệu quả hơn.
• Công cụ chưa trưởng thành: Nhiều nhóm vẫn thiếu các giải pháp đáng tin cậy để tạo dữ liệu đối kháng, tự động hóa các biến thể của prompt và theo dõi phạm vi bảo hiểm hành vi.
• Cách tiếp cận chắp vá chiếm ưu thế: Nếu không có khuôn khổ thống nhất, nhiều nhóm kết hợp các giải pháp một phần bỏ lỡ các rủi ro quan trọng.
• Biến thể tấn công là không đổi: Các loại tấn công mới hoặc các biến thể nhỏ của các loại đã biết xuất hiện hàng ngày. Một payload được mã hóa trong base64 hoặc được nhúng trong PDF có thể bỏ qua các bộ lọc sẽ bắt được phiên bản văn bản thuần túy. Những biến thể này làm cho việc phát hiện nhất quán trở nên cực kỳ khó khăn.
• Độ phức tạp đa phương thức: Kiểm tra các hệ thống AI kết hợp tầm nhìn, ngôn ngữ và các đầu vào khác (như giọng nói hoặc hình ảnh) đặc biệt khó khăn. Các danh mục này vẫn chưa trưởng thành từ góc độ bảo mật, nhưng các cuộc tấn công đã được quan sát, bao gồm cả trong lập chỉ mục red teaming của Mend AI.

Trong khi đó, những kẻ tấn công không chờ đợi. Mọi hệ thống do AI điều khiển được xuất xưởng mà không có kiểm tra đối kháng đều làm tăng khả năng tiếp xúc.

Những Gì Các Nhóm Thông Minh Đang Làm

Các tổ chức có tư duy tiến bộ đang xây dựng các chương trình bảo mật AI phản ánh những thực tế mới này. Họ:

• Phát triển các mô hình mối đe dọa phù hợp với các ứng dụng AI của họ
• Ưu tiên kiểm tra cho các hành vi có rủi ro cao như rò rỉ dữ liệu nhạy cảm, tấn công prompt và trốn tránh chính sách
• Xác định ranh giới hành vi, không chỉ ranh giới kỹ thuật
• Tích hợp red teaming tự động vào các quy trình CI/CD
• Sử dụng các khuôn khổ mở để mô phỏng tấn công chuyên biệt 
• Triển khai các trình dọn dẹp và giảm thiểu cụ thể cho hệ thống trên các tác nhân và LLM. Những biện pháp bảo vệ này phải được điều chỉnh cho phù hợp với các hành vi độc đáo của từng hệ thống AI.
• Mời các chuyên gia tư vấn để phân tích sâu, có tính rủi ro cao

Quan trọng nhất, họ nhận ra rằng bảo mật AI có nghĩa là kiểm tra cách nó hoạt động dưới áp lực – không chỉ cách nó được xây dựng.

Giải thích thuật ngữ:

• LLM (Large Language Model): Mô hình ngôn ngữ lớn, một loại mô hình AI có khả năng hiểu và tạo ra văn bản giống con người dựa trên lượng lớn dữ liệu văn bản mà nó được huấn luyện.
• AST (Application Security Testing): Kiểm thử bảo mật ứng dụng, một tập hợp các phương pháp và công cụ được sử dụng để xác định các lỗ hổng bảo mật trong ứng dụng.
• SAST (Static Application Security Testing): Kiểm thử bảo mật ứng dụng tĩnh, một phương pháp kiểm tra mã nguồn của ứng dụng để tìm các lỗ hổng bảo mật tiềm ẩn mà không cần thực thi mã.
• SCA (Software Composition Analysis): Phân tích thành phần phần mềm, một quá trình xác định các thành phần phần mềm nguồn mở và của bên thứ ba được sử dụng trong một ứng dụng, đồng thời đánh giá các rủi ro bảo mật và tuân thủ liên quan đến các thành phần đó.
• CI/CD (Continuous Integration/Continuous Deployment): Tích hợp liên tục/Triển khai liên tục, một phương pháp phát triển phần mềm trong đó các thay đổi mã được tích hợp thường xuyên và được triển khai tự động vào môi trường sản xuất.
• Prompt Injection: Tấn công Prompt, một kỹ thuật tấn công trong đó kẻ tấn công chèn các lệnh độc hại vào đầu vào của mô hình AI để thao túng hành vi của mô hình.
• Jailbreak: Vượt ngục, một kỹ thuật tấn công trong đó kẻ tấn công tìm cách vượt qua các hạn chế và biện pháp bảo vệ được tích hợp trong mô hình AI.
• Hallucination: Ảo giác, một hiện tượng trong đó mô hình AI tạo ra thông tin sai lệch hoặc vô nghĩa.
• Red Teaming: Hoạt động kiểm tra bảo mật bằng cách đóng vai kẻ tấn công để tìm ra các lỗ hổng trong hệ thống.
• AppSec: Viết tắt của Application Security, là quá trình bảo vệ ứng dụng khỏi các mối đe dọa bảo mật.