ความปลอดภัยไซเบอร์ตอนนี้ทำงานเหมือน Proof of Work

 (dbreunig.com)
6 คะแนน โดย GN⁺ 14 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • LLM ‘Mythos’ ของ Anthropic ทำงานได้เร็วและแม่นยำกว่ามนุษย์ในการจำลองการโจมตีเครือข่ายที่ซับซ้อน และเปิดให้เข้าถึงเฉพาะนักพัฒนาหลักจำนวนจำกัด
  • ในการทดสอบของ AI Security Institute นั้น Mythos จำลองการโจมตีเครือข่ายองค์กร 32 ขั้นตอน ได้สำเร็จสมบูรณ์ 3 ครั้งจาก 10 ครั้ง และ ยิ่งเพิ่มงบประมาณโทเค็น ประสิทธิภาพก็ยิ่งดีขึ้น
  • ผลลัพธ์นี้ชี้ให้เห็นว่า ความปลอดภัยกำลังเปลี่ยนเป็น โครงสร้างที่ต้องทุ่มโทเค็นมากกว่าฝั่งผู้โจมตีจึงจะป้องกันได้ หรือก็คือ การแข่งขันแบบ Proof of Work
  • หลังเหตุโจมตีซัพพลายเชนของ LiteLLM·Axios ความพยายามในการแทนที่การพึ่งพาโอเพนซอร์สด้วย LLM หรือ เพิ่มความปลอดภัยด้วยการทุ่มโทเค็น กำลังแพร่หลาย
  • ปัจจุบันปัจจัยชี้ขาดของความปลอดภัยไม่ใช่ความคิดสร้างสรรค์ทางเทคนิค แต่เป็น ปริมาณทรัพยากรที่投入 และกำลังนำไปสู่แนวโน้มการเพิ่มขั้นตอน ‘hardening’ ในกระบวนการพัฒนา

โครงสร้างที่ความปลอดภัยทำงานเหมือน ‘Proof of Work’

  • LLM ‘Mythos’ ของ Anthropic แสดงประสิทธิภาพโดดเด่นในงานด้านความปลอดภัยคอมพิวเตอร์ จึงเปิดให้เข้าถึงเฉพาะผู้สร้างซอฟต์แวร์หลักโดยยังไม่เปิดสู่สาธารณะ
    • Mythos สามารถจำลองการโจมตีเครือข่ายที่ซับซ้อนได้เร็วกว่ามนุษย์อย่างมาก
    • ในการประเมินของ AI Security Institute (AISI) ก็พิสูจน์ความสามารถในการ ดำเนินการโจมตีไซเบอร์ ที่สูงกว่ารุ่นก่อนหน้าอีกระดับ
  • ในการจำลองการโจมตีเครือข่ายองค์กร 32 ขั้นตอนชื่อ ‘The Last Ones’ Mythos ทำสำเร็จครบถ้วน 3 ครั้งจาก 10 ครั้ง
    • AISI ใช้ 100 ล้านโทเค็น (ราว 12,500 ดอลลาร์) ต่อความพยายามหนึ่งครั้ง
    • ในบรรดาโมเดลที่ทดสอบ มีเพียง Mythos เท่านั้นที่โจมตีได้ครบทั้งหมด และ ยิ่งเพิ่มงบประมาณโทเค็น ประสิทธิภาพก็ยังดีขึ้นต่อเนื่อง
  • ผลลัพธ์นี้ทำให้เศรษฐศาสตร์ของความปลอดภัยสรุปได้เป็นสมการง่าย ๆ ว่า “หากจะป้องกันได้ ต้องใช้โทเค็นมากกว่าที่ผู้โจมตีใช้”
    • การเสริมความปลอดภัยถูกกำหนดโดย ปริมาณทรัพยากรที่投入 มากกว่าความคิดสร้างสรรค์
    • นี่เป็นโครงสร้างที่คล้ายกับกลไก Proof of Work ของคริปโตเคอร์เรนซี ซึ่งฝ่ายที่ทุ่มทรัพยากรการคำนวณมากกว่าจะเป็นฝ่ายชนะ

นัยสำคัญของเศรษฐศาสตร์ความปลอดภัยแบบใหม่

  • ความสำคัญของซอฟต์แวร์โอเพนซอร์สที่มากขึ้น

    • หลังการโจมตีซัพพลายเชนของ LiteLLM และ Axios เมื่อไม่นานมานี้ บางฝ่ายเริ่มเสนอให้สร้างโค้ดส่วนพึ่งพาใหม่ด้วย AI agent
    • Andrej Karpathy กล่าวไว้ว่า “ควรประเมิน dependencies ใหม่ และฟังก์ชันที่เรียบง่ายควรสร้างตรงด้วย LLM จะดีกว่า”
    • หากความปลอดภัยแปรผันตามปริมาณโทเค็นที่投入 ก็เป็นไปได้ว่า ยิ่งบริษัททุ่มโทเค็นเพื่อเสริมความปลอดภัยให้ไลบรารีโอเพนซอร์ส ก็ยิ่งปลอดภัยขึ้น
    • อย่างไรก็ดี OSS ที่ถูกใช้อย่างแพร่หลายมีมูลค่าในการโจมตีสูง จึงทำให้ ฝั่งผู้โจมตีก็มีแรงจูงใจที่จะทุ่มทรัพยากรมากขึ้นเช่นกัน

  • การเพิ่มขั้นตอน ‘Hardening’ ในกระบวนการพัฒนา

    • ปัจจุบันนักพัฒนามักทำงานตามกระบวนการ 2 ขั้นคือ พัฒนา → รีวิวโค้ด โดยใช้คนละโมเดลในแต่ละขั้น
    • Anthropic มีบริการเฉพาะสำหรับรีวิวโค้ด (Code Review) โดยมีค่าใช้จ่ายราว 15–20 ดอลลาร์ต่อการรีวิวหนึ่งครั้ง
    • ในอนาคต วงจร 3 ขั้น พัฒนา → รีวิว → hardening อาจกลายเป็นเรื่องปกติ
      1. พัฒนา: สร้างฟังก์ชันและวนปรับปรุงจากฟีดแบ็กผู้ใช้
      2. รีวิว: จัดทำเอกสาร รีแฟกเตอร์ และยกระดับคุณภาพ
      3. Hardening: ดำเนินการ ค้นหาช่องโหว่อัตโนมัติ ภายในขอบเขตงบประมาณที่มี
    • ขั้นแรกถูกจำกัดด้วยเวลาของมนุษย์ ขณะที่ขั้นสุดท้ายมี ต้นทุน เป็นปัจจัยจำกัด

โครงสร้างต้นทุนและขีดจำกัดของความปลอดภัย

  • การเขียนโค้ดยังคงมีต้นทุน ต่ำ แต่หากต้องการให้ปลอดภัย ก็จำเป็นต้อง ซื้อโทเค็นให้มากกว่าฝั่งผู้โจมตี
  • แม้ประสิทธิภาพด้านการอนุมานของโมเดลจะดีขึ้น แต่ ต้นทุนการเสริมความปลอดภัยถูกกำหนดโดยมูลค่าของการโจมตี จึงยากที่จะลดต้นทุนได้อย่างสมบูรณ์
  • ผลลัพธ์คือ ความปลอดภัยกำลังเปลี่ยนจากเรื่องของความคิดสร้างสรรค์ทางเทคนิค ไปเป็น การแข่งขันด้านทรัพยากรที่ขับเคลื่อนโดยตลาด

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 14 일 전
ความคิดเห็นจาก Hacker News

  • การเข้าถึงโค้ดเบสคือหัวใจสำคัญ ตอนนี้การ สแกนความปลอดภัยด้วย LLM แทบจะเป็นแค่สคริปต์ bash ง่ายๆ ที่ไล่วนทุกไฟล์แล้วโยนพรอมป์ต์ว่า “ช่วยหาช่องโหว่ให้หน่อย”
    แต่ถ้าฝั่งป้องกันควบคุมซอร์สทั้งหมดได้ ก็ทำงานได้มีประสิทธิภาพกว่ามาก เช่น สแกนเฉพาะไฟล์ที่เปลี่ยนในระดับ PR หรือทุ่มโทเคนมากขึ้นให้โค้ดที่เกี่ยวกับความปลอดภัย ผู้โจมตีต้องสแกนใหม่ทุกครั้ง แต่ฝ่ายป้องกันสแกนครั้งเดียวก็หาโอกาสเกิดช่องโหว่ทั้งหมดได้ล่วงหน้า
    สุดท้ายแล้วจึงมี ความไม่สมมาตรของต้นทุน อยู่จริง และฝั่งป้องกันได้เปรียบในด้านประสิทธิภาพ ผู้โจมตีต้องทำ exploit chain หลายขั้นให้สำเร็จ แต่ฝ่ายป้องกันแค่บล็อกจุดอ่อนที่สุดจุดเดียวในนั้นก็พอ

    • ผู้โจมตีมีจำนวนมาก แต่ผู้ป้องกันมีแค่หนึ่งเดียว จะบอกว่า economy of scale เข้าข้างฝ่ายป้องกันจึงฟังดูยอมรับได้ยาก การสมมุติว่าเข้าถึงโค้ดไม่ได้เป็นแนวคิดที่ไม่ดีในเชิงความปลอดภัย เพราะ การรีวิวความปลอดภัย ทุกแบบตั้งอยู่บนสมมุติฐานว่ามีสิทธิ์เข้าถึงซอร์ส
    • ถึงอย่างนั้น แนวทางนี้ก็ทำให้ต้นทุนการพัฒนาซอฟต์แวร์สูงขึ้น ท่าทีชะล่าใจแบบ “คงไม่มีใครมาเล่นงานเราหรอก” ใช้ไม่ได้อีกต่อไป
    • อย่างที่พูดถึงในพอดแคสต์ Security Cryptography Whatever ตอนล่าสุด น่าสนใจที่ตอนนี้ “กลยุทธ์รอโมเดลรุ่นถัดไป” ดูจะมีประสิทธิภาพกว่าการปรับปรุงฮาร์เนส
    • ปัญหาคือแนวทางนี้อาจทำให้เหตุการณ์ระดับ “เครื่องของนักพัฒนาคนหนึ่งติดมัลแวร์ใน supply chain attack” ลุกลามเป็น “ซอร์สโค้ดทั้งชุดรั่วไหลและถูกตรวจสอบอัตโนมัติ” โลกแบบนั้นน่าจะเป็นป่ามืดสำหรับสตาร์ตอัป
    • ฝ่ายป้องกันต้องทำให้แข็งแรงทุกจุด แต่ผู้โจมตีต้องหาเจอแค่ช่องโหว่เดียวก็พอ

  • AI Security Institute (AISI) ที่บทความพูดถึงน่าสนใจ เลยลองไปดูเพิ่มแล้วพบว่าเป็นองค์กรที่มีคนจาก DeepMind หรือ OpenAI เข้ามามีส่วนร่วมเป็นหลัก แทบไม่มีคนจากวงการความปลอดภัยเลย จึงทำให้ข้อสรุปแบบ “ถ้าอยาก harden ระบบก็ต้องใช้โทเคนมากขึ้น” ฟังดูเป็น ตรรกะที่ยึดมุมมองอุตสาหกรรม AI อยู่พอสมควร และก็สงสัยว่าทำไมทางเลือกอย่าง formal verification ถึงไม่ถูกพูดถึง นึกภาพได้เลยว่า NVIDIA อาจหยิบตรรกะแบบนี้ไปใช้ขาย GPU ได้

    • สงสัยว่าใครบ้างที่เป็นนักวิจัยความปลอดภัยชื่อดังและน่าจะมีจุดยืนคัดค้านมุมมองนี้ เพราะในทางปฏิบัติดูเหมือนนักวิจัยจำนวนมากจะเห็นด้วยอยู่ ตอนนี้ประเด็นหลักของการถกเถียงคือ LLM เป็น นวัตกรรมระดับ fuzzing หรือไปไกลกว่านั้น
    • เพิ่มเติมคือ AISI เป็นหน่วยงานภายใต้รัฐบาลสหราชอาณาจักร สังกัดกระทรวงวิทยาศาสตร์ นวัตกรรม และเทคโนโลยี (DSTI) แต่รูปแบบการวิเคราะห์ เช่น การลากกราฟเป็นเส้นตรงแบบง่ายๆ ก็ยังน่าผิดหวังอยู่บ้าง

  • คำพูดของ Tony Hoare ที่ว่า “การออกแบบซอฟต์แวร์มีอยู่สองแนวทาง คือทำให้ง่ายจนไม่มีข้อบกพร่อง หรือทำให้ซับซ้อนจนมองไม่เห็นข้อบกพร่อง” เป็นคำคมที่โดดเด่นมาก

    • ต่อให้ทำให้ง่ายสุดๆ ก็ป้องกันการโจมตีได้ไม่หมด แต่ ผลของการลด attack surface นั้นใหญ่ทีเดียว เช่น ถ้าออกแบบให้ต้องตรวจสอบลายเซ็นก่อนประมวลผลข้อความเครือข่าย ก็จะทำให้ยอมรับข้อความที่ไม่ได้เซ็นได้ยากขึ้น หลายระบบทุกวันนี้มี threat model กว้างเกินความจำเป็น
    • แต่เกณฑ์ของคำว่า “ซับซ้อน” อาจไม่เหมือนกันสำหรับมนุษย์กับ LLM สิ่งที่ดูซับซ้อนสำหรับคน อาจเป็นเรื่องง่ายสำหรับ LLM ก็ได้ จึงยังน่าสงสัยว่าแนวทางนี้จะใช้ได้ผลแค่ไหน

  • ความปลอดภัยเป็น เกมของการดูว่าคู่แข่งยอมจ่ายมากแค่ไหน มาตลอด การมี LLM ไม่ได้เปลี่ยนหลักการนั้น สิ่งที่ Karpathy พูดเรื่องแนวคิด “คัดลอกแทนพึ่งพา dependency” ก็มีอยู่ในสุภาษิตของภาษา Go มานานแล้ว เช่นเดียวกับหลักการที่ว่า “ความปลอดภัยไม่ได้มาจากการซ่อน” ซึ่งก็เป็นข้อเท็จจริงเก่าแก่

    • แต่ obscurity ก็ไม่ได้ไร้ความหมายไปเสียทีเดียว มันช่วยได้ในฐานะหนึ่งในหลายชั้นของการป้องกัน วิธีที่เหมาะคือทำระบบให้แข็งแรงโดยสมมุติว่าทุกอย่างโปร่งใสทั้งหมดก่อน แล้วค่อยเพิ่มความไม่โปร่งใสเข้าไปเล็กน้อยด้านบน
    • คำพูดที่ว่า “จะป้องกันได้ต้องใช้โทเคนมากกว่าผู้โจมตีใช้” ไม่ใช่เรื่องใหม่ ในโลกความปลอดภัยทางกายภาพก็เป็นแบบเดียวกัน สุดท้ายในยุค AI เราก็ต้อง ใช้ AI ป้องกัน AI และจุดแรกที่ควรตรวจคือพรอมป์ต์ของโมเดลสร้างโค้ดที่นักพัฒนาใช้งาน

  • โดยรวมเห็นด้วยกับบทความ ข้อความว่า “เราไม่ได้ให้คะแนนความฉลาด” ฟังดูอันตรายอยู่บ้าง แก่นแท้ของ ไซเบอร์ซีเคียวริตีคือระบบของมนุษย์ อยู่ดี การใช้เวลา GPU จำนวนมากเป็นเรื่องจำเป็น แต่ท้ายที่สุดแล้ว วัฒนธรรมและวินัยด้านความปลอดภัย ขององค์กรต่างหากที่ชี้ขาดแพ้ชนะ เราจำเป็นต้องมีวินัยระดับเดียวกับที่อุตสาหกรรมนิวเคลียร์หรือการบินพัฒนาขึ้นหลังเกิดอุบัติเหตุ
    ในบริบทนี้ บทความนี้ เมื่อปีก่อนอธิบายสถานการณ์ตอนนี้ได้แทบเหมือนทำนายไว้ล่วงหน้า

  • สำหรับข้ออ้างที่ว่า “ถ้าอยาก harden ระบบต้องใช้โทเคนมากกว่าผู้โจมตี” ผมเคยเขียนสคริปต์เองเพื่อทำ Ticketmaster API automation มาก่อน พวกเขาเสริมการป้องกันด้วย PerimeterX แต่ผมก็ bypass ได้ภายใน 3 วัน ไม่นานมานี้ผมยังทำวิธี bypass Cloudflare Turnstile ของ ChatGPT ในลักษณะคล้ายกันได้ด้วย
    นี่เป็นตัวอย่างที่แสดงให้เห็นว่าผลิตภัณฑ์ความปลอดภัยที่สร้างด้วยเงินหลายสิบล้านดอลลาร์ แท้จริงแล้ว ไร้ประโยชน์สิ้นดี
    โพสต์ HN ที่เกี่ยวข้อง

  • อยากรู้ว่าเหตุการณ์ด้านความปลอดภัยที่ LLM ค้นพบได้นั้นเป็นช่องโหว่ใหม่จริงๆ หรือแค่เป็นส่วนต่อยอดจากองค์ความรู้ด้านความปลอดภัยเดิม ถ้าเป็นอย่างหลัง ก็ชวนสงสัยว่าทำไมเราถึงค้นหาอย่างเป็นระบบด้วยตัวเองไม่ได้

  • เหตุผลที่งานวิจัยนี้ดูเหมือน Proof of Work ก็เพราะ AISI ระบุว่า “ยิ่งใช้โทเคนมาก ผลลัพธ์ก็ยังเพิ่มขึ้นต่อเนื่อง” กล่าวคือสมมุติฐานคืออัตราความสำเร็จของการโจมตีแปรผันตามปริมาณโทเคนที่ใช้ แต่การทดลองเป็นสถานการณ์เจาะเครือข่าย 32 ขั้น และมีเพียง Mythos โมเดลเดียวที่ทำสำเร็จ สำหรับไลบรารีโค้ดที่เรียบง่ายกว่า จุดที่ผลตอบแทนลดลง อาจมาถึงเร็วกว่านี้มาก
    โปรเจกต์โอเพนซอร์สน่าจะทำให้ทั้งฝ่ายป้องกันและผู้โจมตีต้องใช้โทเคนมากขึ้น จึงอาจชนเพดานนี้ได้เร็วกว่า

    • Mythos ก็ไม่ได้สำเร็จทุกครั้ง และเครือข่ายทดลองก็ไม่ได้มีระบบป้องกันจริงเหมือนสภาพแวดล้อมจริง ถึงอย่างนั้นก็ไม่มีเหตุผลให้ประเมิน AI ต่ำเกินไป โมเดลในอีก 3 เดือนข้างหน้าคงไปอยู่อีกระดับหนึ่งแล้ว
    • ผมไม่ได้รู้เรื่องไซเบอร์ซีเคียวริตีมากนัก แต่คิดว่าแก่นสำคัญน่าจะอยู่ที่ อัตราการเพิ่มขึ้นของต้นทุนโทเคน จากขั้นที่ 32 ไป 33 ถ้าการป้องกันเป็นอิสระกันในแต่ละขั้น โอกาสสำเร็จของการโจมตีก็น่าจะลดฮวบแบบ p^N

  • สุดท้ายคำถามคือ — การปกป้องโค้ดเบสที่มนุษย์เขียนมีต้นทุนถูกกว่า หรือการปกป้อง โค้ดที่สร้างโดยฝูงเอเจนต์ มีต้นทุนถูกกว่ากัน

  • การโยนโมเดลเข้าใส่ทั้งโค้ดเบสแบบสะเปะสะปะเหมือนตอนนี้ไม่มีประสิทธิภาพ จากที่ผมทดลองมา ถ้าปรับโมเดลให้สำรวจ source-to-sink trace อย่างมีโครงสร้าง ต้นทุนจะลดลงอย่างมาก
    ตอนนี้เราเข้าสู่ยุคที่ระบบสามารถ มองภาพบริบทของโค้ดทั้งก้อนและชี้รอยร้าวได้อย่างแม่นยำ แล้ว และนี่จะเป็นจุดเปลี่ยนสำคัญในการยกระดับคุณภาพซอฟต์แวร์