💡 RetroLab đánh giá cao quan điểm của tác giả về việc duy trì tiêu chuẩn xác thực trong kỷ nguyên AI. Team RetroLab cho rằng bài viết là lời nhắc nhở kịp thời cho các đội ngũ bảo mật: công nghệ là công cụ, không phải là sự thay thế cho phán xét của con người.
Trí tuệ nhân tạo (AI) đang thay đổi cục diện an ninh tấn công (offensive security), nhưng nó chưa thể thay đổi tiêu chuẩn quan trọng nhất: một phát hiện phải được chứng minh trước khi trở nên hữu ích. Các công cụ hỗ trợ AI có thể đọc mã nguồn nhanh chóng, tạo payload, tóm tắt bề mặt tấn công, giải thích các API lạ, và chạy các quy trình kiểm thử lặp đi lặp lại với tốc độ ấn tượng. Đó là một lợi thế thực sự cho các đội ngũ bảo mật. Nhưng nó cũng tạo ra một áp lực mới, bởi vì ngành công nghiệp giờ đây có thể tạo ra nhiều đầu ra trông giống lỗ hổng hơn bao giờ hết.
Vấn đề là đầu ra không đồng nghĩa với bằng chứng. Một báo cáo được tạo ra có thể nghe có vẻ chuyên nghiệp, bao gồm điểm nghiêm trọng, và thậm chí chứa một bằng chứng khái niệm (proof-of-concept) trông có vẻ hợp lý ngay từ cái nhìn đầu tiên. Không điều nào trong số đó chứng minh lỗ hổng tồn tại trong môi trường triển khai thực tế. Không điều nào chứng minh khả năng khai thác, tác động, hay rủi ro. Trong kiểm thử tấn công, phần khó khăn chưa bao giờ là viết ra thứ gì đó nghe giống như một báo cáo lỗ hổng. Phần khó khăn là chứng minh điều gì thực sự đúng.
Sự khác biệt đó đang trở nên quan trọng hơn khi AI ngày càng phổ biến trong các quy trình bảo mật. AI có thể tăng tốc quá trình khám phá, nhưng việc xác thực vẫn phụ thuộc vào kiến thức: kiến thức về hệ thống, giao thức, hành vi ứng dụng, ranh giới định danh, lỗi hỏng bộ nhớ, logic kinh doanh, và tất cả các chi tiết triển khai giúp phân biệt một giả thuyết có vẻ hợp lý với một cuộc khai thác thực sự. Tương lai của an ninh tấn công sẽ không thuộc về những người chỉ đơn thuần tạo ra số lượng phát hiện lớn nhất. Nó sẽ thuộc về những người và đội ngũ có thể chứng minh được điều gì thực sự quan trọng.
Ngành công nghiệp đã thấy cái giá của đầu ra AI nông cạn
Những dấu hiệu cảnh báo đã xuất hiện. Các chương trình bug bounty và người bảo trì đã phải đối mặt với làn sóng báo cáo chất lượng thấp do AI tạo ra, thường đi kèm với bằng chứng mỏng, ngôn ngữ khuôn mẫu, và ít xác thực có ý nghĩa. Bugcrowd đã công khai đề cập đến vấn đề này trong các thay đổi chính sách về các bài gửi do AI tạo ra, mô tả một loại báo cáo trông có vẻ trau chuốt nhưng lại tạo ra gánh nặng phân loại không cần thiết thay vì một tín hiệu bảo mật hữu ích.
Đây không chỉ là vấn đề của bug bounty. Đó là hình ảnh trước về những gì sẽ xảy ra ở bất kỳ đâu khi AI được sử dụng để tạo ra các phát hiện bảo mật mà thiếu sự phán xét của con người. Nếu một công cụ có thể tạo ra một báo cáo thuyết phục trong vài giây, các tổ chức sẽ nhận được nhiều báo cáo hơn, nhiều cảnh báo hơn, và nhiều tuyên bố hơn. Trừ khi những tuyên bố đó được xác thực, kết quả không phải là bảo mật tốt hơn. Nó chỉ là một hàng đợi lớn hơn.
Các đội ngũ bảo mật vốn đã quá tải với đầu ra từ scanner, cảnh báo phụ thuộc, vấn đề cấu hình đám mây, và các phát hiện tuân thủ. Thêm vào đó những suy đoán do AI tạo ra sẽ không giúp ích gì trừ khi chất lượng cũng được nâng lên cùng lúc. Một phát hiện nên trả lời rõ ràng các câu hỏi cơ bản: điều gì đã xảy ra, nó được tái tạo như thế nào, kẻ tấn công kiểm soát được gì, ranh giới nào đã bị vượt qua, và tác động đã được chứng minh là gì. Nếu không có những điều đó, báo cáo có thể thú vị, nhưng nó chưa sẵn sàng để thúc đẩy hành động kỹ thuật.
“Trông có vẻ dễ bị tấn công” không đồng nghĩa với dễ bị tấn công
Một trong những thói quen nguy hiểm nhất trong kiểm thử tấn công là nhầm lẫn một mẫu đáng ngờ với một lỗ hổng đã được xác thực. AI có thể làm cho thói quen đó tồi tệ hơn vì nó giỏi giải thích tại sao một thứ gì đó có thể là xấu. Một mô hình có thể thấy đầu vào của người dùng gần một truy vấn cơ sở dữ liệu và mô tả SQL injection. Nó có thể thấy một URL fetch và gợi ý SSRF. Nó có thể thấy một API nguy hiểm trong một đường dẫn mã và mô tả remote code execution. Đôi khi mô hình chỉ ra một vấn đề thực sự. Những lúc khác, nó bỏ lỡ các điều kiện quyết định liệu vấn đề có quan trọng hay không.
Một người kiểm thử vẫn phải chứng minh khả năng tiếp cận (reachability). Đầu vào do kẻ tấn công kiểm soát có thực sự đến được thao tác nguy hiểm không? Có yêu cầu xác thực không? Có phân quyền được thực thi ở nơi khác không? Tính năng dễ bị tấn công có được bật không? Cấu hình sản xuất có lộ đường dẫn mã không? Ứng dụng có chuẩn hóa, mã hóa, làm sạch, hoặc từ chối payload trước khi nó có tác dụng không? Vấn đề có vượt qua ranh giới tin cậy hay chỉ ảnh hưởng đến một đường dẫn nội bộ không có tác động bảo mật thực tế?
Những câu hỏi này là nơi an ninh tấn công thực sự bắt đầu. Chúng cũng là nơi tự động hóa nông cạn thường thất bại. AI có thể tạo ra các giả thuyết nhanh chóng, nhưng giả thuyết không phải là phát hiện. Một người kiểm thử giỏi coi đầu ra của AI như một manh mối để điều tra, không phải một kết luận để chuyển tiếp.
Tại sao kiến thức vẫn quan trọng
Những chuyên gia an ninh tấn công giỏi nhất có giá trị vì họ hiểu hệ thống, không phải vì họ có thể chạy các công cụ. Công cụ luôn là một phần của công việc, nhưng đầu ra của công cụ chưa bao giờ là đủ. Một web scanner có thể xác định một tham số phản ánh đầu vào. Một static analyzer có thể gắn cờ một hàm nguy hiểm. Một fuzzer có thể tạo ra một sự cố. Một mô hình ngôn ngữ có thể mô tả một đường dẫn tấn công khả thi. Trong mọi trường hợp, ai đó vẫn cần hiểu tín hiệu đó có nghĩa là gì.
Sự hiểu biết đó thường có được thông qua lặp đi lặp lại. Các nhà nghiên cứu kỳ cựu đã dành nhiều năm làm việc thủ công: theo dõi các yêu cầu, đọc mã nguồn, dịch ngược các tệp nhị phân, gỡ lỗi sự cố, viết mã khai thác, phá vỡ các luồng xác thực, và học cách các hệ thống thực sự thất bại. Quá trình đó xây dựng trí nhớ và bản năng. Nó dạy cho một người thực hành khi nào một phát hiện có thể là thật, khi nào một công cụ bị đánh lừa, và khi nào một lỗi nhỏ có thể trở nên nghiêm trọng nếu kết hợp với thứ khác.
Loại kiến thức này rất khó để giả mạo. Nó thể hiện trong các câu hỏi mà người kiểm thử đặt ra. Nó thể hiện trong cách viết báo cáo. Nó thể hiện trong việc người kiểm thử có thể giải thích đường dẫn khai thác mà không ẩn sau ngôn ngữ chung chung hay không. Quan trọng nhất, nó thể hiện khi nỗ lực đầu tiên thất bại. Một người hiểu hệ thống có thể thích nghi. Một người chỉ chấp nhận lời giải thích của công cụ thường bị mắc kẹt.
AI có thể giúp người kiểm thử giỏi nhanh hơn, nhưng cũng có thể làm họ trở nên lụt nghề
Có một mối lo ngại thực sự trong số các chuyên gia giàu kinh nghiệm rằng sự phụ thuộc quá mức vào AI có thể làm cho con người trở nên lụt nghề. Đây không phải là một lập luận chống AI. Đó là một lập luận về học tập của con người. Khi một công cụ trả lời mọi câu hỏi ngay lập tức, sẽ rất dễ dàng để ngừng ghi nhớ chi tiết. Khi nó viết phiên bản đầu tiên của mọi tập lệnh, sẽ rất dễ dàng để ngừng thực hành. Khi nó giải thích mọi đường dẫn mã, payload, sự cố, và thông báo lỗi, sẽ rất dễ dàng để ngừng xây dựng mô hình tinh thần của riêng bạn.
Sự tiện lợi đó có một cái giá. An ninh tấn công đề cao chiều sâu, nhận dạng mẫu, và khả năng ghi nhớ kỹ thuật. Những phát hiện khó khăn nhất thường đến từ việc nhận ra rằng một hành vi trong một khu vực vi phạm một giả định ở nơi khác. Chúng đến từ việc biết cách các trình phân tích cú pháp, framework, bộ cấp phát, nhà cung cấp danh tính, và hệ thống phân quyền đã thất bại trước đây. Chúng đến từ việc thấy mối liên hệ giữa các chi tiết nhỏ trông không quan trọng khi đứng riêng lẻ.
Nếu các chuyên gia ngừng rèn luyện những cơ bắp đó, họ sẽ mất đi một phần kỹ năng khiến họ hiệu quả. Rủi ro không phải là AI làm cho các chuyên gia bảo mật trở nên vô dụng. Rủi ro là con người để AI làm quá nhiều việc suy nghĩ quá sớm, sau đó nhầm lẫn sự trôi chảy với năng lực. Prompting rất hữu ích, nhưng nó không thể thay thế cho sự phán xét.
Hầu hết kiểm thử hỗ trợ AI vẫn sử dụng các kỹ thuật quen thuộc
Nhiều tiếp thị về AI trong bảo mật có thể làm cho nó nghe như thể machine learning đang khám phá các lỗ hổng thông qua một loại lý luận hoàn toàn mới. Đôi khi các mô hình phát hiện ra các mẫu mà con người có thể bỏ lỡ, đặc biệt là trên các cơ sở mã lớn và không quen thuộc. Điều đó rất hữu ích. Nhưng trong nhiều quy trình kiểm thử tấn công thực tế, các kỹ thuật cơ bản vẫn quen thuộc: liệt kê các endpoint, kiểm tra tham số, theo dõi luồng dữ liệu, so sánh hành vi đã xác thực và chưa xác thực, tạo payload, chạy fuzzer, quan sát phản hồi, và xác định xem trạng thái ứng dụng có thay đổi theo cách liên quan đến bảo mật hay không.
Nói cách khác, nhiều hệ thống hỗ trợ AI đang điều phối các kỹ thuật kiểm thử đã biết ở quy mô lớn. Chúng có thể lập kế hoạch, thực thi, quan sát, và lặp lại nhanh hơn một con người làm mọi thứ bằng tay. Đó là một cải tiến có ý nghĩa, nhưng nó không loại bỏ nhu cầu hiểu kết quả. Nếu hệ thống báo cáo một lỗ hổng phân quyền, ai đó vẫn phải biết liệu mối quan hệ đối tượng có quan trọng hay không. Nếu nó báo cáo một lỗi hỏng bộ nhớ, ai đó vẫn phải suy luận về khả năng tiếp cận, ngữ cảnh sự cố, các biện pháp giảm thiểu, và khả năng khai thác. Nếu nó báo cáo một điểm yếu API, ai đó vẫn phải xác định xem hành vi quan sát được có vi phạm mô hình tin cậy của ứng dụng hay không.
Cách sử dụng AI có giá trị nhất không phải là thay thế những quyết định đó. Nó là để giảm bớt công việc cơ học xung quanh chúng, để những người kiểm thử có kỹ năng có thể dành nhiều thời gian hơn cho phân tích và xác thực.
Xác thực tốt trông như thế nào
Một phát hiện tấn công đã được xác thực nên cụ thể, có thể tái tạo, và gắn liền với tác động. Nó không nên yêu cầu người đọc phải đoán tại sao vấn đề lại quan trọng. Báo cáo nên làm rõ đường dẫn khai thác đủ để một kỹ sư có thể tái tạo và một lãnh đạo bảo mật có thể hiểu được rủi ro. Điều đó không có nghĩa là mọi vấn đề đều cần một chuỗi khai thác kịch tính hoặc một bằng chứng khái niệm kiểu phim ảnh. Nó có nghĩa là bằng chứng nên hỗ trợ cho tuyên bố.
Đối với kiểm thử hỗ trợ AI, các đội ngũ nên vạch ra một ranh giới rõ ràng giữa manh mối (leads) và phát hiện đã xác thực. Một manh mối là thứ đáng để điều tra. Một phát hiện đã xác thực là thứ đã được kiểm tra và chứng minh. Trộn lẫn các loại này tạo ra sự nhầm lẫn và lãng phí thời gian. Một quy trình làm việc tốt hoàn toàn có thể sử dụng AI để tạo ra các manh mối, nhưng việc thăng cấp từ manh mối lên phát hiện nên yêu cầu bằng chứng.
Danh sách kiểm tra xác thực thực tế
Một tiêu chuẩn xác thực thực tế không cần phải phức tạp. Trước khi một manh mối trở thành một phát hiện được báo cáo, người kiểm thử nên có thể trả lời các câu hỏi như:
- Hành vi cụ thể nào đã được quan sát, và nó xảy ra ở đâu?
- Đầu vào, danh tính, hoặc trạng thái nào do kẻ tấn công kiểm soát là cần thiết?
- Ranh giới bảo mật nào đã bị vượt qua, chẳng hạn như xác thực, phân quyền, đa khách hàng (tenancy), tin cậy, đặc quyền, hoặc an toàn bộ nhớ?
- Các bước chính xác nào tái tạo hành vi trong môi trường mục tiêu?
- Tác động đã được chứng minh là gì, không chỉ là trường hợp xấu nhất về mặt lý thuyết?
- Bằng chứng nào cho thấy vấn đề có thể tiếp cận và có liên quan trong cấu hình đã triển khai?
- Một bản sửa lỗi sẽ cần thay đổi những gì, và đội ngũ có thể xác nhận rằng bản sửa lỗi hoạt động như thế nào?
Loại danh sách kiểm tra này giúp giữ AI ở đúng vai trò. Nó có thể giúp tạo ra các ứng cử viên, đề xuất ý tưởng kiểm tra, và tăng tốc tái tạo. Nó không nên được phép bỏ qua bước mà con người xác minh tuyên bố so với thực tế.
Vai trò của con người vẫn mang tính kỹ thuật
Một trong những thực tế ít được đánh giá cao của các nền tảng bảo mật AI là xác thực của con người vẫn cực kỳ quan trọng ở hậu trường. Điều đó không có gì đáng ngạc nhiên. An ninh tấn công luôn đòi hỏi sự phán xét, và sự phán xét đặc biệt quan trọng khi các phát hiện trở nên hệ trọng. Người xem xét bằng chứng phải quyết định xem đường dẫn khai thác có thực tế không, môi trường có quan trọng không, vấn đề là riêng lẻ hay có thể kết hợp, và tuyên bố về mức độ nghiêm trọng có chính đáng không.
Đây không chỉ là một chức năng kiểm soát chất lượng hành chính. Đó là công việc kỹ thuật. Các lỗ hổng phân quyền thường phụ thuộc vào logic kinh doanh và mối quan hệ đối tượng. Các lỗ hổng API có thể yêu cầu hiểu cách các vai trò, khách hàng thuê bao (tenants), và tài nguyên tương tác với nhau. Lỗi hỏng bộ nhớ đòi hỏi suy luận về trạng thái sự cố, khả năng kiểm soát, các biện pháp giảm thiểu, và các nguyên thủy khai thác. Các phát hiện trên đám mây phụ thuộc nhiều vào danh tính, chính sách tin cậy, và hành vi cụ thể của dịch vụ. AI có thể hỗ trợ tất cả những điều này, nhưng nó không loại bỏ nhu cầu về một người biết họ đang nhìn vào cái gì.
Tác động của một phát hiện càng cao, vai trò của con người càng quan trọng. Các tổ chức không muốn một phỏng đoán tự tin khi kết quả có thể ảnh hưởng đến các ưu tiên kỹ thuật, lòng tin của khách hàng, nghĩa vụ tuân thủ, hoặc quyết định rủi ro của ban lãnh đạo. Họ cần bằng chứng.
Tránh phóng đại tác động
Các báo cáo do AI tạo ra cũng có thể phóng đại mức độ nghiêm trọng. Đầu vào phản xạ (reflected input) không phải là cross-site scripting cho đến khi việc thực thi script được chứng minh. Một URL fetch không phải là SSRF có ý nghĩa cho đến khi người kiểm thử có thể chỉ ra quyền truy cập vào thứ mà kẻ tấn công không nên với tới. Một hàm nguy hiểm không phải là remote code execution trừ khi khả năng tiếp cận, kiểm soát, và thực thi có thể được chứng minh. Những sai lầm này không chỉ đáng xấu hổ; chúng làm xói mòn lòng tin giữa đội ngũ bảo mật và đội ngũ kỹ thuật. Nó thường xảy ra rằng một phát hiện sẽ được đánh giá CVSS 9.8, trong khi thực tế nó thậm chí có thể không phải là một phát hiện.
Các nhà nghiên cứu giàu kinh nghiệm cẩn thận với tác động vì họ biết nó phải được kiếm được. Một lỗi trong một tính năng chỉ dành cho quản trị viên không mang cùng rủi ro như một lỗi không xác thực trên internet. Một sự cố có thể là một denial of service, một con đường dẫn đến code execution, hoặc đơn giản là một vấn đề độ tin cậy không thể khai thác, tùy thuộc vào ngữ cảnh. Một kiểm tra bị thiếu trong một đường dẫn mã có thể nghiêm trọng, hoặc nó có thể được bảo vệ bởi một kiểm soát ở nơi khác. Cách duy nhất để biết là xác thực.
Xác thực tốt ngăn chặn cả việc báo cáo thiếu và báo cáo quá mức. Nó giúp người kiểm thử tránh 'kêu cứu' sai, nhưng nó cũng cung cấp cho họ bằng chứng cần thiết để đưa ra một trường hợp mạnh mẽ khi vấn đề thực sự nghiêm trọng. Tenable gần đây cũng đã nêu ra những thách thức trong lĩnh vực này, bao gồm cách có những kết hợp ngữ cảnh quan trọng cũng bị bỏ lỡ.
Các đội ngũ nên sử dụng AI như thế nào mà không mất kỹ năng
Mục tiêu đúng đắn không phải là tránh AI. Công nghệ quá hữu ích để làm điều đó. Mục tiêu đúng đắn là sử dụng nó theo cách tăng cường kiểm thử tấn công thay vì làm suy yếu những người thực hiện nó. AI nên giúp người kiểm thử di chuyển nhanh hơn, khám phá nhiều giả thuyết hơn, và giảm công việc lặp đi lặp lại. Nó không nên trở thành một sự thay thế cho việc học cách các hệ thống hoạt động.
Các lãnh đạo bảo mật có thể khuyến khích sự cân bằng đó bằng cách đặt ra kỳ vọng về bằng chứng và đào tạo. Những người kiểm thử mới vào nghề vẫn nên học các nguyên tắc cơ bản trước khi họ thuê ngoài quá nhiều quy trình. Những người kiểm thử kỳ cựu nên sử dụng AI như một hệ số nhân lực, không phải như một cơ quan có thẩm quyền. Các đội ngũ nên xem xét không chỉ liệu một phát hiện đã được tạo ra, mà còn liệu người kiểm thử có thể giải thích và tái tạo nó hay không. Lời giải thích đó là nơi sự hiểu biết thực sự trở nên rõ ràng.
Một chương trình kiểm thử tấn công hỗ trợ AI lành mạnh nên thưởng cho tác động đã được xác thực hơn là số lượng. Nó nên đo lường chất lượng tín hiệu, không chỉ đếm số lượng phát hiện. Nó nên duy trì thực hành thủ công trong các lĩnh vực như thao tác yêu cầu, đánh giá mã, gỡ lỗi, phát triển khai thác, mô hình hóa mối đe dọa, và phân tích tác động. Nó cũng nên sử dụng AI như một công cụ giảng dạy: khi mô hình gợi ý một vấn đề, người kiểm thử nên hỏi tại sao, kiểm tra tuyên bố, và học hỏi từ kết quả.
Tiêu chuẩn vẫn không thay đổi: Hãy chứng minh nó
AI sẽ tiếp tục cải thiện. Các tác nhân (agents) sẽ trở nên tốt hơn trong việc điều hướng ứng dụng, đọc mã, tạo payload, và ghi lại kết quả. Một số tiến bộ này sẽ thực sự ấn tượng, và các đội ngũ bảo mật nên tận dụng nó. Nhưng an ninh tấn công không thể trở thành một trò chơi về số lượng, nơi mọi giả thuyết có vẻ hợp lý trở thành gánh nặng phân loại của người khác.
Tiêu chuẩn cốt lõi của lĩnh vực này vẫn đơn giản: hãy chứng minh nó. Chứng minh lỗ hổng tồn tại. Chứng minh kẻ tấn công có thể tiếp cận nó. Chứng minh tác động. Chứng minh rủi ro kinh doanh. Chứng minh bản sửa lỗi hoạt động. AI không hạ thấp tiêu chuẩn đó. Nếu có gì, nó càng làm tăng tầm quan trọng của việc thực thi tiêu chuẩn, bởi vì đầu ra thuyết phục nhưng chưa được chứng minh giờ đây dễ tạo ra hơn bao giờ hết.
Những nhà nghiên cứu và đội ngũ giỏi nhất của thập kỷ tới sẽ không phải là những người từ chối AI. Họ sẽ là những người kết hợp tự động hóa với phán xét kỹ thuật, sử dụng máy móc để tăng tốc công việc mà không trao cho nó quyền quyết định cuối cùng. Biết khi nào nên dừng lại, kiểm tra, thử nghiệm, và suy nghĩ sẽ vẫn là một lợi thế cạnh tranh. Kiến thức vẫn quan trọng vì xác thực vẫn quan trọng, và trong an ninh tấn công, xác thực là sự khác biệt giữa tiếng ồn và sự thật.
Nguồn: The Hacker News - https://thehackernews.com/2026/07/ai-can-find-bugs-but-human-knowledge.html
