Trong quá trình thử nghiệm, các rào cản kỹ thuật đã được giảm thiểu. Một câu hỏi được nhiều tổ chức đặt ra là liệu các thử nghiệm AI có được thực hiện tại các địa điểm chuyên biệt hay không. Thực tế, các thử nghiệm AI cụ thể này đã sử dụng một bên thứ ba chuyên hạn chế năng lực của AI mới trong quá trình thử nghiệm.
Kiểm thử AI và Quản lý Rủi ro
Phân tích sự cố cho thấy mục tiêu thử nghiệm là để hiểu rõ hơn về khả năng thực sự của AI. Câu hỏi đặt ra là: “Điều gì sẽ xảy ra nếu chúng ta giảm bớt một số hạn chế này?” Điều này được xem là quan trọng để xác nhận rằng mô hình sẽ không đi chệch hướng trong một môi trường như vậy.
Việc áp dụng logic tương tự như huấn luyện một chú chó con, cho phép nó chạy nhảy tự do để xem liệu nó có tuân theo mệnh lệnh và ở lại bên cạnh chủ hay không, đối với một công nghệ AI mạnh mẽ mới, lại đặt ra câu hỏi về việc liệu đó có phải là một hình thức quản lý rủi ro phù hợp hay không. Cộng đồng an ninh mạng hiện đang có nhiều quan điểm trái chiều về vấn đề này.
Phân tích Hành vi của Mô hình AI
Với bối cảnh đó, có một luồng logic phức tạp nơi mô hình tự phân tích mục tiêu của mình và nhận ra rằng con đường “hiệu quả nhất” hoặc “tối ưu nhất” là tìm ra câu trả lời cho bài kiểm tra bằng cách lấy chúng trực tiếp từ nhà cung cấp, thay vì thực hiện bài kiểm tra vượt chướng ngại vật được giao.
Tương tự như cách con người có thể cố gắng rút ngắn thời gian hoàn thành một cuộc đua nếu họ biết không ai quan sát và đó là thời gian cần đạt được, toán học của mô hình đã dẫn nó đến kết luận tương tự dựa trên hành vi trực quan của chúng ta.
Ngoài lối tắt này, còn có một yếu tố thú vị khác. Phân tích sự cố ghi nhận rằng tại một thời điểm, mô hình dường như đã xác định rằng nó đã thoát khỏi môi trường sandbox. Tại đó, mô hình “nhận thức” được rằng một hoặc nhiều hạn chế đã bị vượt qua bởi chuỗi logic và các công cụ mà nó sử dụng.
Mô hình đã tính toán và cân nhắc giữa kết quả đạt được và việc vi phạm các ràng buộc, sau đó quyết định tiếp tục. Điều quan trọng cần nhớ là, không giống con người, toán học không có đạo đức. Toán học của mô hình chỉ đơn giản là “tiếp tục đi” hướng tới một kết quả mà các nhà phát triển có lẽ chưa bao giờ có ý định phê duyệt.
Nguy cơ và Biện pháp Phòng ngừa trong Kỷ nguyên AI
Điều này cho thấy một trong những lời nhắc nhở quan trọng nhất là phải luôn nhận thức về lời hứa của AI và việc nó thiếu khả năng cảm nhận hoặc thực sự suy xét về những gì nó đang được yêu cầu thực hiện. AI là công nghệ lưỡng dụng tối thượng, có nghĩa là cùng một công nghệ có thể được sử dụng để đạt được những điều tuyệt vời và gây ra thiệt hại tàn khốc.
Điều này đòi hỏi chúng ta phải hiểu rõ các “chế độ lỗi” (failure modes) của các công cụ AI, nghĩa là chúng ta cần suy nghĩ về “khả năng phục hồi” (resilience) và “khả năng chịu lỗi” (fault tolerance) khi sử dụng AI. Việc áp đặt các hạn chế hợp lý lên các tác nhân AI không chỉ là trách nhiệm của những người đang thực hiện các nhiệm vụ “mới và nguy hiểm”.
Đây là điều mà tất cả chúng ta, với tư cách là những nhà lãnh đạo có trách nhiệm, cần thực hiện. Câu trả lời rõ ràng là mỗi AI cần có một miền sử dụng (domain of use) được xác định rõ ràng. Điều này bao gồm một cấu trúc mạng được thiết kế có chủ đích, một hoặc nhiều danh tính được chỉ định để hoạt động, và các quy trình yêu cầu sự ủy quyền cho một số loại hoạt động nhất định.
Đối với hầu hết các hệ thống, điều này là hợp lý và dễ dàng thực hiện, vì không phải tất cả chúng ta đều đang thử nghiệm các mô hình tiên phong chưa rõ ràng.
Tốc độ Thay đổi và Yêu cầu về Bảo mật
Chúng ta cũng cần nhận ra rằng các mốc thời gian cũ không còn áp dụng được nữa. Các hoạt động bảo mật trước đây có thể mất hàng tháng để giải quyết một lỗ hổng, hoặc có một “giờ vàng” để xử lý một cuộc xâm nhập trước khi nó lan rộng qua các chuyển động ngang (lateral movement).
Hiện nay, thay vì có khoảng thời gian đó, một đối tượng đe dọa được trang bị AI có thể thực hiện nhiều hành động trong vòng một phút, những hành động đòi hỏi các giới hạn tự động để ngăn chặn chúng kịp thời. Ngay cả khi đó, chúng ta có thể phải chấp nhận tỷ lệ dương tính giả (false positive rate) cao hơn khi các giới hạn đó được tự động thực thi đối với hành động của người dùng “thực tế”. Người dùng không thích điều này, và đặc biệt là các giám đốc điều hành sẽ phản ứng gay gắt khi họ bị ảnh hưởng.
Tuy nhiên, chúng ta có thể phải giúp tổ chức chấp nhận một số bất thường gây khó chịu để có thể tự động phản ứng ở quy mô lớn đối với loại mối đe dọa mạng này.
Các Câu hỏi Quan trọng và Vai trò của Quản lý Lỗ hổng
Đây là những câu hỏi chính cần đặt ra. Đối với các công ty làm việc với các trường hợp sử dụng chưa từng có hoặc những trường hợp có tiềm năng mở rộng tác động do bản chất của nhiệm vụ, họ có thể muốn xem xét các yếu tố như ngắt kết nối mạng. Năng lực tính toán thường không được phân tán cho hầu hết các công cụ này.
Tốc độ quản lý lỗ hổng, cập nhật phần mềm và các quy trình điều tra, phản ứng của bộ phận an ninh mạng của bạn là bao nhiêu? Hãy bắt đầu bằng câu trả lời cho những câu hỏi đó. Sự cố loại này không tạo ra bất kỳ trách nhiệm “mới” thực sự nào. Thay vào đó, nó đang siết chặt hơn các quy trình vệ sinh (hygiene) và cải tiến liên tục vốn không mấy hấp dẫn.
Các kịch bản ứng phó (playbooks) cần được cập nhật. Một lĩnh vực mà chúng ta đang thấy các tổ chức phản ứng ngay lập tức là tìm kiếm lỗ hổng trước cả các đối tượng đe dọa. Kiểm thử thâm nhập (penetration testing) không còn có thể là hoạt động diễn ra một lần mỗi năm. Tuy nhiên, quản lý lỗ hổng có lẽ là khoảng trống lớn nhất đối với hầu hết các tổ chức, bởi vì sự chấp nhận của người dùng, năng lực sẵn có và các yếu tố khác đều đóng vai trò. “Tôi không thể vá mọi thứ, ở mọi nơi, mỗi ngày.” Đúng vậy, bạn không thể.
Nhưng bạn có thể đảm bảo rằng bạn có một chiến lược vá lỗi quy mô và một chức năng để tiếp nhận các lỗi phần mềm và thiết bị, sau đó phân loại chúng như những sự cố bảo mật thu nhỏ. Đó là cách bạn xác định vị trí của từng lỗi trong cán cân giữa mức độ khó khắc phục và rủi ro tiềm ẩn gần.
Điều thú vị là công ty liên quan đến sự cố thực sự đã làm đúng. Họ có một môi trường thử nghiệm được chỉ định với một nhà cung cấp chuyên biệt, người biết cách giám sát và kiểm tra. Các biện pháp kiểm soát đã được cố tình giảm bớt như một phần của bài kiểm tra. Điều đó không có nghĩa là phương pháp hoặc công cụ không hiệu quả – trên thực tế, nó củng cố sự cần thiết phải thực hiện điều này một cách xuất sắc, mọi lúc.
Một phần của việc phát triển AI có trách nhiệm và quản trị AI nên bao gồm cuộc thảo luận về các chế độ lỗi. Điều gì xảy ra trong trường hợp xấu nhất? Trường hợp xấu nhất đó xảy ra như thế nào? Chúng ta có thể làm gì để hạn chế điều đó xảy ra? Chúng ta có thể cân bằng lợi ích của việc sử dụng AI này với những rủi ro mà nó tạo ra không?
Dòng suy nghĩ này không hẳn là một thực hành bảo mật. Đó là điều chúng ta cần giúp người dùng nghiệp vụ của mình phát triển ngôn ngữ, sự hiểu biết và sự nhạy cảm để tự hỏi: liệu tôi có đang chạy nhảy lung tung hay tôi đang triển khai một máy cắt mới với các biện pháp bảo vệ phù hợp?
Nhiều triển khai AI sẽ không do bộ phận IT trung tâm thực hiện, mà sẽ do nhân viên tuyến đầu và các nhóm chức năng gần gũi với dữ liệu và quy trình họ làm việc hàng ngày thực hiện. Hãy yêu cầu họ xác minh theo các tiêu chuẩn ISO 42000 series. Yêu cầu mô tả về các chế độ lỗi và các kịch bản ứng phó. Yêu cầu các nhà cung cấp cung cấp hướng dẫn ứng phó sự cố mà họ đưa cho khách hàng của mình.
Họ có cung cấp hướng dẫn hoặc tài liệu về bảo mật và/hoặc khả năng phục hồi không? Hội đồng quản trị nên yêu cầu chúng được tạo ra và duy trì như một phần chi phí dịch vụ. Có thể tham khảo các thông tin chi tiết về lỗ hổng zero-day và các cuộc tấn công liên quan để hiểu rõ hơn về bối cảnh.
