An ninh mạng giờ vận hành như Proof of Work

• LLM ‘Mythos’ của Anthropic thực hiện các mô phỏng tấn công mạng phức tạp nhanh và chính xác hơn con người, và chỉ được cấp quyền truy cập cho một số nhà phát triển nòng cốt
• Trong bài kiểm tra của AI Security Institute, Mythos hoàn thành trọn vẹn mô phỏng tấn công mạng doanh nghiệp gồm 32 bước 3 lần trên 10 lần thử, và hiệu năng tăng lên khi tăng ngân sách token
• Kết quả này cho thấy bảo mật đang chuyển thành một cấu trúc mà muốn phòng thủ thì phải投入 nhiều token hơn kẻ tấn công, tức một cuộc cạnh tranh kiểu Proof of Work
• Sau các vụ tấn công chuỗi cung ứng vào LiteLLM và Axios, ngày càng xuất hiện nhiều nỗ lực thay thế phụ thuộc mã nguồn mở bằng LLM hoặc tăng cường bảo mật bằng cách投入 token
• Bảo mật đang trở thành lĩnh vực mà lượng tài nguyên bỏ vào mới là yếu tố quyết định hơn là tính sáng tạo kỹ thuật, kéo theo xu hướng bổ sung bước ‘hardening’ vào quy trình phát triển

---

Cấu trúc nơi bảo mật vận hành như ‘Proof of Work’

• LLM ‘Mythos’ của Anthropic cho thấy hiệu năng vượt trội trong các bài toán an ninh máy tính, nên không được công khai rộng rãi mà chỉ cho các nhà phát triển phần mềm chủ chốt truy cập
  • Mythos thực hiện các mô phỏng tấn công mạng phức tạp nhanh hơn con người rất nhiều
  • Trong đánh giá của AI Security Institute (AISI), mô hình này cũng chứng minh năng lực thực hiện tấn công mạng cao hơn một bậc so với các mô hình trước đó
• Trong mô phỏng tấn công mạng doanh nghiệp 32 bước mang tên ‘The Last Ones’, Mythos hoàn thành toàn bộ 3 lần trên 10 lần thử
  • AISI sử dụng 100 triệu token (khoảng 12.500 USD) cho mỗi lần thử
  • Trong số các mô hình được kiểm tra, chỉ Mythos hoàn tất toàn bộ cuộc tấn công, và hiệu năng tiếp tục tăng khi ngân sách token lớn hơn
• Kết quả này cho thấy kinh tế học của bảo mật quy về một công thức đơn giản: “muốn phòng thủ được thì phải dùng nhiều token hơn kẻ tấn công sử dụng”
  • Việc tăng cường bảo mật được quyết định bởi mức đầu tư tài nguyên nhiều hơn là sự sáng tạo
  • Đây là cấu trúc tương tự cơ chế Proof of Work của tiền mã hóa, nơi bên bỏ vào nhiều tài nguyên tính toán hơn sẽ chiến thắng

Hàm ý của nền kinh tế bảo mật mới

• Tầm quan trọng ngày càng lớn của phần mềm mã nguồn mở

  • Sau các vụ tấn công chuỗi cung ứng gần đây nhắm vào LiteLLM và Axios, đã xuất hiện đề xuất tái hiện thực mã phụ thuộc bằng các AI agent
  • Andrej Karpathy nhận định rằng “các dependency cần được đánh giá lại, và với các chức năng đơn giản thì tốt hơn nên triển khai trực tiếp bằng LLM”
  • Nếu mức độ an toàn tỷ lệ với lượng token投入 vào, thì doanh nghiệp càng投入 token vào thư viện mã nguồn mở để tăng cường bảo mật thì có thể càng an toàn hơn
  • Tuy nhiên, các OSS được dùng rộng rãi có giá trị tấn công cao, nên kẻ tấn công cũng có động lực投入 nhiều tài nguyên hơn

• Bổ sung giai đoạn ‘Hardening’ vào quy trình phát triển

  • Hiện nay, các lập trình viên đang theo quy trình 2 bước phát triển → review code, với các mô hình khác nhau được dùng cho từng bước
  • Anthropic cung cấp dịch vụ chuyên cho review code (Code Review), với chi phí khoảng 15~20 USD mỗi lần review
  • Trong tương lai, chu kỳ 3 bước phát triển → review → hardening có thể trở thành chuẩn phổ biến
    1. Phát triển: triển khai tính năng và lặp lại dựa trên phản hồi người dùng
    2. Review: tài liệu hóa, refactor, cải thiện chất lượng
    3. Hardening: thực hiện tự động dò tìm lỗ hổng trong phạm vi ngân sách cho phép
  • Ở bước đầu, thời gian của con người là yếu tố chính; ở bước cuối, chi phí trở thành yếu tố giới hạn

Cấu trúc chi phí và giới hạn của bảo mật

• Việc viết code tự thân vẫn còn rẻ, nhưng để đảm bảo an toàn thì phải mua nhiều token hơn kẻ tấn công
• Dù hiệu quả suy luận của mô hình có được cải thiện, chi phí tăng cường bảo mật vẫn do giá trị của mục tiêu tấn công quyết định, nên khó có thể giảm chi phí hoàn toàn
• Kết quả là, bảo mật đang chuyển từ bài toán sáng tạo kỹ thuật sang một cuộc cạnh tranh tài nguyên mang tính thị trường

[GN⁺]

Ý kiến trên Hacker News

• Quyền truy cập vào codebase là yếu tố cốt lõi. Quét bảo mật dựa trên LLM hiện nay về cơ bản chỉ ở mức một script bash đơn giản, đi qua mọi tệp rồi ném prompt kiểu “hãy tìm lỗ hổng”
  Nhưng nếu bên phòng thủ kiểm soát toàn bộ mã nguồn thì họ có thể vận hành hiệu quả hơn nhiều. Ví dụ, chỉ quét các tệp thay đổi theo từng PR hoặc phân bổ nhiều token hơn cho phần mã liên quan đến bảo mật. Kẻ tấn công phải quét lại từ đầu mỗi lần, còn bên phòng thủ có thể chủ động tìm toàn bộ lỗ hổng tiềm ẩn chỉ với một lần quét
  Rốt cuộc vẫn tồn tại bất đối xứng chi phí, và phía phòng thủ có lợi thế về hiệu quả. Kẻ tấn công phải hoàn thành chuỗi exploit nhiều bước, nhưng bên phòng thủ chỉ cần chặn một mắt xích yếu nhất trong số đó

  • Kẻ tấn công thì nhiều còn bên phòng thủ chỉ có một, nên khó mà bị thuyết phục bởi lập luận rằng lợi thế kinh tế theo quy mô lại nghiêng về phía phòng thủ. Giả định không thể truy cập mã nguồn là không tốt về mặt bảo mật. Mọi đánh giá bảo mật đều lấy quyền truy cập mã nguồn làm tiền đề
  • Dù vậy, cách tiếp cận này vẫn làm tăng chi phí phát triển phần mềm. Thái độ chủ quan kiểu “ai mà nhắm riêng vào chúng ta chứ” sẽ không còn hiệu quả
  • Như có nhắc trong podcast gần đây Security Cryptography Whatever, điều thú vị là lúc này “chiến lược chờ model tiếp theo” lại hiệu quả hơn so với cải tiến harness
  • Vấn đề là cách tiếp cận này có thể đẩy một sự cố ở mức “tấn công chuỗi cung ứng do PC của một lập trình viên bị nhiễm” thành “rò rỉ toàn bộ mã nguồn và bị kiểm toán tự động”. Một thế giới như vậy có lẽ sẽ tạo ra môi trường kiểu rừng tối cho các startup
  • Bên phòng thủ phải gia cố mọi nơi, còn kẻ tấn công chỉ cần tìm đúng một lỗ hổng

• Tôi thấy AI Security Institute (AISI) được nhắc trong bài khá thú vị nên đã tìm hiểu thử, và hóa ra đây là tổ chức chủ yếu do những người xuất thân từ DeepMind hay OpenAI tham gia. Gần như không có người từ ngành bảo mật. Vì vậy kết luận rằng “muốn gia cố hệ thống thì phải dùng nhiều token hơn” nghe hơi giống một logic lấy ngành AI làm trung tâm. Cũng khó hiểu vì sao các phương án thay thế như formal verification lại không được nhắc đến. Tôi còn nghĩ NVIDIA hoàn toàn có thể dùng kiểu lập luận này để bán GPU

  • Tôi tò mò không biết có nhà nghiên cứu bảo mật nổi tiếng nào sẽ đứng ở phía phản đối quan điểm này không. Trên thực tế có vẻ nhiều nhà nghiên cứu lại đồng ý với lập luận đó. Trọng tâm tranh luận lúc này là liệu LLM có phải là một bước đột phá cỡ fuzzing, hay còn hơn thế nữa
  • Tham khảo thêm thì AISI là cơ quan thuộc chính phủ Anh, nằm dưới Bộ Khoa học, Đổi mới và Công nghệ (DSTI). Tuy vậy cách phân tích, chẳng hạn như vẽ đồ thị tuyến tính đơn giản, vẫn khá đáng tiếc

• Câu nói của Tony Hoare rất ấn tượng: “Có hai cách tiếp cận trong thiết kế phần mềm: hoặc đơn giản đến mức không có khiếm khuyết, hoặc phức tạp đến mức không nhìn ra khiếm khuyết”

  • Làm mọi thứ hoàn toàn đơn giản không thể chặn được mọi cuộc tấn công, nhưng tác dụng giảm bề mặt tấn công là rất lớn. Ví dụ, nếu thiết kế sao cho luôn phải xác thực chữ ký trước khi xử lý thông điệp mạng, thì sẽ khó chấp nhận các thông điệp chưa được ký. Nhiều hệ thống hiện nay có mô hình đe dọa rộng hơn mức cần thiết
  • Nhưng tiêu chuẩn của “độ phức tạp” lại khác nhau giữa con người và LLM. Thứ trông phức tạp với con người có thể lại đơn giản với LLM. Vì vậy cũng khó nói cách tiếp cận này còn hiệu quả đến đâu

• Bảo mật từ trước đến nay luôn là cuộc chơi xem đối phương chịu chi bao nhiêu tiền. Sự xuất hiện của LLM không làm thay đổi nguyên lý đó. Triết lý “copy thay vì phụ thuộc” mà Karpathy nói tới thực ra đã tồn tại từ lâu như một châm ngôn của ngôn ngữ Go. Nguyên tắc “không thể có bảo mật nhờ che giấu” cũng là điều cũ kỹ từ lâu

  • Tuy nhiên obscurity không hẳn là hoàn toàn vô nghĩa. Nó có thể hữu ích như một trong nhiều lớp phòng thủ. Lý tưởng nhất là trước tiên phải gia cố hệ thống trong giả định nó hoàn toàn minh bạch, rồi mới thêm lên trên một chút mức độ không minh bạch
  • Câu “muốn phòng thủ thì phải dùng nhiều token hơn kẻ tấn công” cũng không phải ý mới. Trong bảo mật vật lý cũng vậy. Rốt cuộc ở thời đại AI, ta vẫn phải dùng AI để phòng thủ trước AI. Trước mắt có lẽ nên kiểm tra từ chính các prompt của model sinh mã mà lập trình viên đang dùng

• Tôi nhìn chung đồng ý với nội dung bài viết. Câu “không chấm điểm bằng sự thông minh” nghe hơi nguy hiểm. Bản chất của an ninh mạng vẫn nằm ở các hệ thống do con người vận hành. Dùng nhiều thời gian GPU hơn là cần thiết, nhưng rốt cuộc văn hóa và kỷ luật bảo mật của tổ chức mới là thứ quyết định thắng bại. Cần một mức độ kỷ luật kiểu chỉ xuất hiện sau tai nạn như trong ngành điện hạt nhân hay hàng không.
  Trong ngữ cảnh liên quan, bài viết này từ một năm trước gần như đã mô tả tình hình hiện tại như một lời tiên tri

• Về lập luận “muốn gia cố hệ thống thì phải dùng nhiều token hơn kẻ tấn công”, tôi từng có kinh nghiệm tự viết script để tự động hóa Ticketmaster API. Họ tăng cường phòng thủ bằng PerimeterX, nhưng tôi vượt qua chỉ sau 3 ngày. Gần đây tôi cũng triển khai cách vượt Cloudflare Turnstile của ChatGPT theo kiểu tương tự.
  Đây là ví dụ cho thấy những sản phẩm bảo mật được tạo ra với chi phí hàng chục triệu đô thực tế lại vô dụng
  Bài HN liên quan

• Tôi tò mò liệu những sự cố bảo mật mà LLM tìm ra có thực sự là lỗ hổng mới hay chỉ là phần tiếp nối của kiến thức bảo mật sẵn có. Nếu là trường hợp sau thì thật khó hiểu vì sao chính chúng ta lại không thể tự tìm ra một cách có hệ thống

• Nghiên cứu này trông giống Proof of Work vì AISI nói rằng “càng dùng nhiều token thì kết quả càng tiếp tục tăng”. Tức là họ giả định tỷ lệ tấn công thành công tỷ lệ thuận với lượng token tiêu thụ. Nhưng thí nghiệm là một kịch bản xâm nhập mạng gồm 32 bước, và model duy nhất hoàn thành được là Mythos. Với các thư viện mã đơn giản hơn, điểm lợi suất giảm dần có thể đến sớm hơn nhiều
  Với các dự án mã nguồn mở, cả bên phòng thủ lẫn tấn công đều có thể phải tiêu tốn nhiều token hơn, và vì vậy có khả năng chạm tới giới hạn này sớm hơn

  • Mythos cũng không thành công trong mọi lần thử, và mạng thí nghiệm cũng không hề có hệ thống phòng thủ thực tế. Dù vậy cũng không có lý do gì để đánh giá thấp AI. Model sau 3 tháng nữa sẽ lại ở một đẳng cấp khác
  • Tôi không hiểu nhiều về an ninh mạng, nhưng có lẽ mấu chốt là tốc độ tăng của chi phí token khi đi từ bước 32 lên bước 33. Nếu phòng thủ độc lập theo từng bước thì xác suất tấn công thành công sẽ giảm rất mạnh theo p^N

• Rốt cuộc câu hỏi là thế này — bảo vệ một codebase do con người viết rẻ hơn, hay bảo vệ mã do cả một đạo quân agent tạo ra rẻ hơn

• Việc ném model vào toàn bộ codebase như hiện nay là không hiệu quả. Theo thử nghiệm của tôi, nếu điều chỉnh model để nó khám phá có cấu trúc theo source-to-sink trace thì chi phí giảm đi rất nhiều.
  Giờ đây đã là thời đại mà hệ thống có thể trực quan hóa ngữ cảnh của toàn bộ mã và chỉ chính xác điểm nứt gãy. Đây sẽ là một bước ngoặt lớn trong việc nâng cao chất lượng phần mềm