Ngộ độc dữ liệu là gì?

Mọi nhóm bảo mật đều được đào tạo để giám sát mã nguồn khi nó được triển khai. Hầu như không ai được đào tạo để giám sát dữ liệu khi nó được đưa vào sử dụng, và điểm mù đó chính là mục tiêu mà việc làm nhiễm độc dữ liệu khai thác. Đến khi một mô hình bị nhiễm độc được đưa vào sản xuất, lỗ hổng này chưa từng được phát hiện trong quá trình xem xét mã nguồn. Nó nằm trong một tập dữ liệu mà không ai kiểm tra lại nhiều tháng trước đó.

Mục từ vựng này giải thích thế nào là tấn công đầu độc dữ liệu, các cuộc tấn công đầu độc dữ liệu diễn ra như thế nào trong thực tế và tại sao tấn công đầu độc dữ liệu bằng trí tuệ nhân tạo lại trở thành một trong những vấn đề được quan tâm hàng đầu. Những rủi ro tăng trưởng nhanh nhất trong kỷ nguyên AI SDLCvà biện pháp phòng thủ thực sự chống lại nó trông như thế nào.

Ý nghĩa của việc đầu độc dữ liệu #

Tấn công đầu độc dữ liệu là hành vi cố ý thao túng dữ liệu được sử dụng để huấn luyện, tinh chỉnh hoặc xây dựng mô hình AI, sao cho mô hình học sai, hoạt động theo cách mà kẻ tấn công mong muốn, hoặc làm rò rỉ thông tin mà nó không bao giờ được phép tiết lộ. Thay vì tấn công mô hình sau khi triển khai, kẻ tấn công tấn công vào nguyên liệu thô mà mô hình được xây dựng từ đó.

Ý tưởng cốt lõi đằng sau việc làm sai lệch dữ liệu rất đơn giản và đáng lo ngại: một mô hình AI chỉ đáng tin cậy khi dữ liệu mà nó được dùng để học cũng đáng tin cậy. Nếu dữ liệu đó bị hỏng, thiên vị hoặc bị cài bẫy trước khi quá trình huấn luyện bắt đầu, thì dù có xem xét mã nguồn, kiểm thử hay giám sát thời gian thực ở giai đoạn sau cũng không thể phát hiện ra lỗi tiềm ẩn, bởi vì mô hình vẫn hoạt động chính xác như những gì nó đã được (một cách ác ý) dạy.

Tấn công đầu độc dữ liệu bằng AI so với các lỗ hổng phần mềm truyền thống #

Bảo mật ứng dụng truyền thống cho rằng mối nguy hiểm nằm ở mã nguồn: một hàm lỗi, một thư viện chưa được vá lỗi, một máy chủ cấu hình sai. Việc đầu độc dữ liệu AI hoàn toàn phá vỡ giả định đó. Không có dòng mã nào dễ bị tổn thương để tìm ra, bởi vì sự hư hỏng đã xảy ra trong tập dữ liệu huấn luyện, tập dữ liệu tinh chỉnh hoặc chỉ mục truy xuất từ ​​rất lâu trước khi bất kỳ mã nào được viết hoặc bất kỳ mô hình nào được triển khai.

Đây là lý do tại sao việc phát hiện các dữ liệu bị nhiễm độc do AI lại đặc biệt khó khăn với các công cụ cũ. SAST Trình quét đọc mã. Trình quét phụ thuộc đọc các tệp kê khai gói. Cả hai đều không đọc một tập dữ liệu huấn luyện nhiều gigabyte hoặc một cơ sở dữ liệu vectơ chứa đầy các tài liệu nhúng, điều này là không thể.cisĐây là nơi mà việc đầu độc dữ liệu bằng AI gây ra thiệt hại. Các nhà nghiên cứu bảo mật đã phát hiện và tiết lộ thông tin một cách có trách nhiệm. Những lỗ hổng khác bị kẻ tấn công phát hiện và sử dụng làm vũ khí trước, đây là kịch bản gây ra thiệt hại lớn nhất.

Các cuộc tấn công làm nhiễm độc dữ liệu hoạt động như thế nào? #

Các cuộc tấn công làm nhiễm độc dữ liệu thường có một vài hình thức sau:

• Ngộ độc dữ liệu đào tạoKẻ tấn công chèn các ví dụ bị thao túng, dán nhãn sai hoặc độc hại vào tập dữ liệu được sử dụng để huấn luyện mô hình từ đầu hoặc tinh chỉnh mô hình hiện có, khiến mô hình học được một thành kiến ​​tiềm ẩn hoặc hành vi cửa hậu.
• Lật nhãnĐây là một phiên bản tinh vi hơn của phương pháp trên, trong đó kẻ tấn công chỉ thay đổi nhãn trên một tập hợp nhỏ các ví dụ huấn luyện, âm thầm làm sai lệch cách mô hình học cách liên kết các dữ liệu với nhau.
• RAG và ngộ độc ngữ cảnhTrong các hệ thống tạo lập dựa trên truy xuất, kẻ tấn công cài đặt các tài liệu độc hại vào cơ sở tri thức hoặc kho lưu trữ vectơ mà mô hình truy xuất trong quá trình thực thi, nhờ đó mô hình tự tin lặp lại thông tin sai lệch hoặc bị thao túng như thể đó là sự thật đã được xác minh.
• Các tác nhân kích hoạt cửa hậu: kẻ tấn công nhúng một mẫu cụ thể trong dữ liệu huấn luyện Do đó, mô hình hoạt động bình thường trong hầu hết mọi trường hợp, nhưng sẽ tạo ra kết quả do kẻ tấn công lựa chọn ngay khi một cụm từ kích hoạt hoặc đầu vào ẩn xuất hiện.
• Ngộ độc chuỗi cung ứng: Kẻ tấn công xâm nhập vào tập dữ liệu công khai hoặc được chia sẻ. một điểm kiểm tra mô hình được huấn luyện trước, hoặc một phần nhúng. pipeline ở phía thượng nguồn, để mọi nhóm ở phía hạ nguồn lấy dữ liệu từ đó đều thừa hưởng chất độc mà không hề chạm vào đòn tấn công ban đầu.

Điểm chung của tất cả các cuộc tấn công làm nhiễm độc dữ liệu này là thời điểm. Thiệt hại xảy ra trước khi mô hình kịp trả lời người dùng thực sự, đó chính là lý do tại sao cụm từ “trước khi nó viết ra một dòng mã nào” lại mô tả mối đe dọa này một cách chính xác đến vậy.cisely: Mô hình bị lỗi ở nền tảng, chứ không phải ở kết quả đầu ra.

Kẻ tấn công làm hỏng mô hình AI như thế nào trước khi nó kịp viết bất kỳ dòng mã nào? #

Mọi cuộc tấn công làm nhiễm độc dữ liệu được mô tả ở trên đều có chung lợi thế về thời gian: sự xâm phạm xảy ra ở khâu đầu vào, rất lâu trước khi mô hình tạo ra bất kỳ đầu ra nào mà người dùng có thể nhìn thấy. Không có chức năng dễ bị tổn thương nào cần vá lỗi và không có mục đích xấu nào. commit Cần phải xem xét lại vì mô hình chưa viết bất cứ thứ gì. Nó chỉ mới học, và những gì nó học được đã sai.

Đây chính là điều khiến việc đầu độc dữ liệu bằng AI khác biệt hoàn toàn so với các lỗ hổng mà các nhóm bảo mật ứng dụng được đào tạo để tìm kiếm. Một mô hình bị cài cửa hậu trông giống hệt một mô hình sạch trong quá trình so sánh mã. Nó vượt qua bài kiểm tra. pull request Đánh giá. Nó biên dịch, triển khai và trả lời hầu hết các truy vấn một cách chính xác, cho đến khi điều kiện cụ thể mà kẻ tấn công cài cắm cuối cùng xuất hiện trong môi trường sản xuất. Đến lúc đó, câu hỏi không còn là "mã nào đã gây ra điều này" nữa, mà là "dữ liệu nào đã gây ra điều này, và nó bắt nguồn từ bao giờ".

Tại sao việc làm sai lệch dữ liệu AI lại trở thành mối quan tâm ngày càng lớn? #

Việc đầu độc dữ liệu AI không còn là mối lo ngại lý thuyết nữa. Nó đã được chính thức công nhận là... LLM04: Nhiễm độc dữ liệu và mô hình Trong danh sách OWASP Top 10 dành cho các ứng dụng LLM, mối đe dọa này sánh ngang với tấn công tiêm mã độc tức thời và rủi ro chuỗi cung ứng, trở thành một trong những mối đe dọa quan trọng nhất của kỷ nguyên trí tuệ nhân tạo tạo sinh. Ba xu hướng đang đẩy mối đe dọa này lên vị trí cao hơn trong tầm ngắm của mọi đội ngũ bảo mật:

• Thiệt hại sẽ không thể nhìn thấy cho đến khi bị kích hoạt. Một mô hình bị nhiễm độc có thể vượt qua mọi bài kiểm tra chức năng và hoạt động hoàn hảo trong nhiều tháng, cho đến khi điều kiện kích hoạt cụ thể mà kẻ tấn công cài đặt cuối cùng xuất hiện trong môi trường sản xuất.

• Công nghệ tạo nội dung được hỗ trợ bởi việc truy xuất thông tin đang hiện diện ở khắp mọi nơi. Bất kỳ hệ thống nào cho phép mô hình lấy ngữ cảnh trực tiếp từ tài liệu, wiki, phiếu yêu cầu hoặc cơ sở dữ liệu vector đều có một bề mặt đầu vào mới, chưa được kiểm soát, và bề mặt đó chính xác là mục tiêu của các cuộc tấn công làm sai lệch dữ liệu.

• Các tập dữ liệu hiện nay là tài sản của chuỗi cung ứng. Các nhóm thường xuyên tải các mô hình được huấn luyện trước, các embedding và các bộ dữ liệu công khai từ các nguồn bên ngoài giống như cách họ tải các gói mã nguồn mở, và cũng giống như một gói phần mềm bị xâm phạm, một bộ dữ liệu bị xâm phạm có thể âm thầm mang theo cuộc tấn công vào mọi nhóm sử dụng nó.

Phát hiện và phòng chống việc đầu độc dữ liệu #

Vì việc làm sai lệch dữ liệu xảy ra ở giai đoạn trước khi mô hình được xây dựng, nên việc phòng vệ cũng phải bắt đầu từ giai đoạn trước đó:

• Hãy chú ý đến các nguồn dữ liệu bất thường, chứ không chỉ là mã nguồn bất thường. Việc phát hiện hành vi và bất thường cần được mở rộng đến nơi dữ liệu được đưa vào. pipelineKhông dừng lại ở ranh giới kho lưu trữ.

• Nắm rõ mọi tập dữ liệu trong pipeline. Bạn không thể kiểm tra rủi ro nhiễm độc dữ liệu trong một tập dữ liệu mà bạn không biết là nó tồn tại. Việc liên tục khám phá các tập dữ liệu huấn luyện, đánh giá và truy xuất là tuyến phòng thủ đầu tiên.

• Theo dõi quá trình hình thành từ tập dữ liệu đến mô hình và kết quả đầu ra. Việc lập bản đồ đường đi của một tập dữ liệu vào mô hình, và từ mô hình vào tác nhân, điểm cuối hoặc công cụ lập trình, chính là điều biến câu nói “chúng ta nhận được kết quả đầu ra không tốt” thành “chúng ta biết chính xác tập dữ liệu nào đã gây ra lỗi đó”.

• Hãy xem xét kỹ các nguồn dữ liệu được sử dụng để truy xuất thông tin, chứ không chỉ riêng các tập dữ liệu huấn luyện. Trong các hệ thống RAG, kho lưu trữ vectơ và cơ sở tri thức cần được kiểm tra tính toàn vẹn tương tự như dữ liệu huấn luyện, vì việc làm sai lệch ngữ cảnh xảy ra trong quá trình truy vấn, chứ không phải trong quá trình huấn luyện.

Xygeni giúp thu hẹp khoảng cách về việc dữ liệu bị nhiễm độc như thế nào? #

Việc phòng chống hiện tượng dữ liệu bị xâm phạm bắt đầu từ khả năng giám sát mà hầu hết các tổ chức hiện nay đều không có. Xygeni'Hệ thống quản lý kho AI của chúng tôi liên tục phát hiện mọi tài sản AI trên toàn hệ thống. SDLCBao gồm cả các tập dữ liệu đằng sau nó: dữ liệu huấn luyện, tập dữ liệu đánh giá và RAG hoặc nguồn truy xuất, và ánh xạ chúng vào một biểu đồ quan hệ trực tiếp chạy từ tập dữ liệu đến mô hình đến điểm cuối. đến tác nhân đến máy chủ MCP Đối với công cụ lập trình. Biểu đồ đó là thứ biến kết quả đầu ra đáng ngờ của mô hình thành một câu hỏi có thể truy vết: tập dữ liệu nào đã cung cấp dữ liệu này và nó đến từ đâu.

Ngoài kho hàng đó, Xygeni's Bảo mật AI Phát hiện các điểm yếu của vectơ và phép nhúng, bao gồm cả ngữ cảnh bị sai lệch trong quá trình truy xuất và RAG. pipelines, được căn chỉnh theo OWASP Top 10 cho hồ sơ ứng tuyển chương trình LLM. Thay vì tin tưởng rằng nguồn dữ liệu huấn luyện và truy xuất của mô hình là sạch, Xygeni coi chúng là một phần của bề mặt tấn công, giống như cách nó xử lý mã nguồn, các phụ thuộc và các yếu tố khác. pipelineNếu hiện tại bạn không thể trả lời câu hỏi “dữ liệu nào đã huấn luyện mô hình này, và chúng ta có thể chứng minh điều đó không?”, thì đó chính là điểm yếu cần khắc phục trước khi một sự cố làm sai lệch dữ liệu AI buộc bạn phải đặt câu hỏi đó.

FAQ #