- Terence Tao กล่าวถึงความสำคัญเชิงตรรกะของการแบ่งแยกระหว่างบลูทีมและเรดทีมในด้าน ความมั่นคงปลอดภัยไซเบอร์
- Constructive logic (ตรรกะเชิงสร้างสรรค์) เป็นตัวแทนของหลักการฝั่งบลูทีม ส่วน co-constructive logic (ตรรกะเชิงร่วมสร้างสรรค์) เป็นตัวแทนของหลักการฝั่งเรดทีม
- Mike Shulman กำลังวิจัยตรรกะแบบใหม่ที่ผสานรากฐานของตรรกะทั้งสองแบบเข้าด้วยกัน
- การตีความแบบ Brouwer–Heyting–Kolmogorov (BHK) เน้นการพิสูจน์เป็นศูนย์กลาง แต่ก็ย้ำถึงความสำคัญของการหักล้างด้วย
- งานวิจัยลักษณะนี้มีศักยภาพในการประยุกต์ใช้กับหลายสาขา เช่น ความปลอดภัยของ AI
การแยกและการผสานตรรกะของ LLM แบบ Blue Team และ Red Team
- Terence Tao กล่าวเมื่อไม่นานมานี้ว่า ในแวดวงความปลอดภัยและอัลกอริทึม นักตรรกะกำลังพิจารณาความแตกต่างระหว่าง Blue Team (ฝ่ายป้องกัน) และ Red Team (ฝ่ายโจมตี) อย่างลึกซึ้งมากขึ้น
- Constructive logic (ตรรกะเชิงสร้างสรรค์) มุ่งเน้นที่กระบวนการตรวจสอบ หรือก็คือกระบวนการพิสูจน์ว่าข้อความหนึ่งเป็นจริง และเป็นตัวกำหนดหลักการของฝั่งบลูทีม
- ในทางกลับกัน co-constructive logic (ตรรกะเชิงร่วมสร้างสรรค์) เป็นตรรกะของกระบวนการหักล้าง หรือก็คือตรรกะที่เกี่ยวกับการโต้แย้งหรือการโจมตี ซึ่งกำลังได้รับความสนใจมากขึ้นในช่วงหลัง และสะท้อนหลักการของฝั่งเรดทีม
งานวิจัยการผสานตรรกะของ Mike Shulman
- Mike Shulman กำลังศึกษาตรรกะในรูปแบบที่ผสานระบบตรรกะทั้งสองนี้เข้าด้วยกัน
- ตามข้อความที่อ้างอิงจากบทความของเขา การตีความแบบ Brouwer–Heyting–Kolmogorov (BHK) ที่มีอยู่เดิมมักให้ความสำคัญกับเกณฑ์การพิสูจน์เป็นหลัก แต่ในมุมมองของนักคณิตศาสตร์ภาคปฏิบัติ เกณฑ์ในการหักล้าง หรือการระบุว่าข้อความใดเป็นเท็จ ก็มีความสำคัญไม่แพ้กัน
- ประเด็นนี้ชี้ให้เห็นข้อจำกัดของแนวคิดแบบเน้นการพิสูจน์เป็นศูนย์กลางในการตีความตรรกะแบบเดิม
ความจำเป็นในการขยายการตีความเชิงตรรกะ
- มีข้อเสนอว่าจำเป็นต้องอธิบายจากทั้งสองมุมมองว่า สำหรับตัวเชื่อมเชิงตรรกะนั้น การพิสูจน์ และ การหักล้าง หมายถึงอะไรบ้าง
- งานวิจัยที่ Mike Shulman กำลังดำเนินการอยู่ กำลังสำรวจว่าการตีความที่ขยายออกไปเช่นนี้จะมีโครงสร้างอย่างไรในทางปฏิบัติ
นัยสำคัญและความเป็นไปได้ในการประยุกต์ใช้
- หากงานวิจัยด้านตรรกะแบบผสานลักษณะนี้เดินหน้าต่อไป ก็มีแนวโน้มสูงว่าจะนำไปใช้ได้จริงในการออกแบบ ความปลอดภัยของ AI หรือในการพัฒนาระบบตรวจสอบและหักล้างอัลกอริทึมในด้านความมั่นคงปลอดภัยไซเบอร์
- รายละเอียดเพิ่มเติมของบทความที่เกี่ยวข้องสามารถดูได้จากลิงก์ arXiv
1 ความคิดเห็น
ความเห็นบน Hacker News
มีความคิดอยู่สองสามอย่าง
(a) AI มีประโยชน์ทั้งกับทีม "red" และ "blue"
ทีม blue ทำหน้าที่คล้ายการระดมความคิดรูปแบบหนึ่ง
(b) AlphaEvolve เป็นกรณีตัวอย่างที่ใช้แนวทาง 'red/blue team' อย่างชัดเจนในความหมายนี้ เพียงแต่ไม่ได้ใช้คำดังกล่าว
Terence Tao ก็เป็นที่ปรึกษาของงานวิจัยฉบับนั้นด้วย
(c) เรื่องนี้ทำให้นึกถึงการแบ่งบทบาท 'ผู้พิสูจน์/ผู้หักล้าง' ใน game semantics
Tao เองก็เคยพูดถึงวิธีคิดแบบนี้ในที่สาธารณะ ดังนั้นจึงน่าจะมองจากมุมนี้อยู่จริง
คำว่า "blue/red" น่าจะเป็นการห่อเรื่องให้เหมาะกับโปรแกรมเมอร์
(d) เสริมอีกนิดว่า จะบอกว่าระบบความปลอดภัยแข็งแกร่งได้แค่เท่าจุดอ่อนที่สุดเสมอไปก็ไม่ถูก
มันขึ้นอยู่กับว่า security ถูกจัดเป็นชั้น ๆ หรือเป็นโครงสร้างขนานกัน
ถ้าเป็นโถงทางเดินที่มีประตูแข็งหลายบานกับประตูอ่อนหลายบานเรียงต่อกัน ความแข็งแกร่งโดยรวมจะถูกกำหนดโดยความแข็งแรงของประตูที่แข็งที่สุด
และถ้าเอา classifier ที่อ่อนหลายตัวมารวมกันทำเป็นอัลกอริทึมตรวจจับการฉ้อโกง มันอาจแข็งแกร่งกว่าตัวที่อ่อนที่สุดมากก็ได้
งานวิจัย AlphaEvolve
Q&A เกี่ยวกับวิธีคิดของ Tao
เพราะสิ่งที่ LLM ทำตรงนั้นมีแค่สร้างโค้ดใหม่จากตัวอย่าง และไม่ได้ประเมินโค้ดเอง
รู้สึกว่าแนวคิด red vs blue team เป็นกรอบที่ดีในการทำความเข้าใจว่า LLM มีประโยชน์กับงานระดับผู้เชี่ยวชาญได้แค่ไหน
เรื่องเพิ่ม tests นั้นแทบจะยกให้ LLM ทำได้แบบไม่ลังเล
เพราะโดยทั่วไป tests มีต้นทุนต่ำ ถ้าผิดก็ลบหรือแก้ได้ง่าย และถ้าถูกก็เพิ่มคุณค่า
แต่ LLM มักไม่ค่อยทดสอบฟังก์ชันหลักบ่อยนัก ดังนั้น tests ที่สำคัญที่สุดยังต้องเขียนเองถึงจะเชื่อถือได้
ในทางกลับกัน การใช้ LLM แก้บั๊กหรือเพิ่มฟีเจอร์เสี่ยงกว่า
เพราะ LLM อาจใช้ทางลัด หรือเขียนโค้ดที่แค่ทำให้ tests ผ่านโดยไม่ได้แก้ปัญหาที่แท้จริง
พอได้ทำงานกับ codebase แบบ legacy ก็รู้สึกอย่างแรงว่าความคิดแบบ "ถึง tests จะผิดก็ไว้ค่อยแก้ทีหลัง" นั้นอันตราย
บางครั้ง tests ก็เป็นหลักฐานที่ใกล้ความจริงยิ่งกว่าโค้ดเสียอีก ดังนั้น test ที่ผิดอาจร้ายแรงกว่าโค้ดที่ผิด
โดยเฉพาะเมื่อมี tests ไร้ประโยชน์หรือความหมายกำกวมปนอยู่ด้วย มันแย่สุด ๆ เวลาต้องแยกว่าอันไหนกำลังพยายามรับประกันพฤติกรรมที่สำคัญจริง
ผมมองว่า AI คล้ายเครื่องคิดเลข
เครื่องคิดเลขคำนวณสิ่งที่คนส่วนใหญ่ทำไม่ได้ได้ดี เช่นเดียวกับที่ AI เป็นเครื่องมือเสริมชนิดใหม่ที่เพิ่มขีดความสามารถให้มนุษย์
หลายคนคิดว่า "AI จะมาแทนมนุษย์" แต่ในความเป็นจริงคุณค่าที่แท้คือการช่วยเสริมงานของมนุษย์
ผมเห็นต่าง
tests ต้องเขียนเองและเข้าใจอย่างถ่องแท้ก่อน จึงจะตั้ง baseline ที่แท้จริงได้ และจากนั้นถึงจะสบายใจให้ AI เปลี่ยนโค้ดตามต้องการ
ถ้า tests เองก็เป็นสิ่งที่ LLM สร้าง ความกังวลต่อการปล่อยให้ AI จัดการโค้ดส่วนที่เหลือจะยิ่งเพิ่มขึ้น
ผมเคยลองให้ LLM สร้าง tests สำหรับโค้ด Rust แต่ในทางปฏิบัติโทษมีมากกว่าประโยชน์
จำนวน tests เยอะก็จริง แต่ขอบเขตสำคัญมักหลุดหาย
พอโค้ดเยอะมากก็ยิ่งดูยากว่าส่วนไหนไม่ได้ถูกครอบคลุม
และถ้าภายหน้าต้องเปลี่ยน logic ของโค้ด ก็ต้องมาไล่แก้ tests ที่ถูกสร้างไว้จำนวนมากทั้งหมด
มีคำพูดว่า "ไม่มีใครตรวจสอบ tests ดังนั้นคนเลยมักถือว่ามันถูกต้อง"
นั่นจึงเป็นที่มาของแพตเทิร์น Arrange-Act-Assert
ทุกวันนี้ unit test ที่ชอบที่สุดคือแบบเก็บค่า input และ expected output เอาไว้ แล้วใช้สิ่งนั้นตรวจผลลัพธ์ของโค้ด
มันทำให้ตรวจ corner cases ได้ง่าย จึงตรวจได้สะดวกว่าโค้ดทำงานตรงตามที่ต้องการจริงไหม
เท่าที่เข้าใจ อัลกอริทึม RSA ก็ถูกสร้างขึ้นในลักษณะนี้เหมือนกัน
ตามหนังสือ "The Code Book" ของ Simon Singh (เคยวางไว้ที่ไหนสักแห่งแต่หาไม่เจอ) Rivest กับ Shamir เป็นคนเสนอไอเดีย ส่วน Adleman รับบทหาข้อบกพร่อง
ดูใน Wikipedia ของ RSA
เป็นอีกตัวอย่างของความร่วมมือแบบ blue/red team ในคณิตศาสตร์
คนหนึ่งมีไอเดียเยอะ พูดเยอะ และค่อนข้างไม่เป็นระเบียบ
อีกคนมีตรรกะและความละเอียดสูง พอคนหนึ่งเขียนดราฟต์งานวิจัย อีกคนก็จะลบส่วนที่ไม่จำเป็นออกหมด
โดยภาพรวมผมเห็นด้วย แต่การ framing ผ่านมุม infosec ดูแปลก ๆ อยู่หน่อย
มุมมองแบบ "ความแข็งแกร่งของ security เท่ากับส่วนที่อ่อนที่สุด" นั้นเรียบง่ายเกินไปและอันตราย
กลยุทธ์ด้าน security ควรถูกออกแบบเป็นการป้องกันหลายชั้น
เราไม่อาจคาดหวังความสมบูรณ์แบบจากชั้นเดียวได้ จึงต้องมีหลายชั้นป้องกัน
การโจมตีกับการป้องกันไม่ได้ต่างกันมากนัก แต่ผู้โจมตีจำนวนมากแทบไม่ต้องรับผิดหากพลาด ขณะที่ฝ่ายป้องกัน โดยเฉพาะองค์กรใหญ่ ต้องรับผิดชอบต่อผลลัพธ์มากกว่า
อย่างไรก็ดี ฝ่ายป้องกันก็มีข้อได้เปรียบจากการสู้ในสนามของตัวเอง ซึ่งถ้ามองข้ามก็อาจเกิดปัญหาได้
ตัวอย่างที่ว่าต่อให้ล็อกประตูแต่เปิดหน้าต่างไว้ก็ไร้ประโยชน์นั้นเป็นอุปมาที่ถูกต้อง
การป้องกันหลายชั้นมีความหมายก็ต่อเมื่อองค์ประกอบที่ผู้โจมตีต้องผ่านเพื่อไปถึงเป้าหมายนั้นถูกซ้อนกันเป็นหลายชั้นจริง ๆ
แต่ถ้าเป็นองค์ประกอบในระดับเดียวกันอย่างประตูกับหน้าต่าง จุดที่อ่อนที่สุดก็จะตัดสินทั้งระบบ
ยกตัวอย่างเว็บ ถ้าหน้า login หลักสมบูรณ์แบบ แต่ endpoint เก่าอย่าง
/v1/legacy/external_backofficeเปิดให้เข้าถึงเครือข่ายภายในได้โดยไม่ต้องยืนยันตัวตน การป้องกันทั้งหมดก็พังถึงอย่างนั้น ถ้าภายในยังมีชั้นป้องกันเพิ่มเติม ความเสียหายก็อาจถูกจำกัดได้ ดังนั้น defense in depth จึงยังสำคัญอยู่
ผมใช้คำว่า "การป้องกันแข็งแกร่งได้เท่ากับห่วงโซ่ที่อ่อนที่สุด" ในความหมายที่กว้างขึ้น
ผมเพิ่มคำว่า 'ความพยายามในการป้องกันทั้งหมด' เข้าไปเกินจากถ้อยคำในโพสต์ต้นฉบับ แต่จริง ๆ แล้วทั้งสองฝั่งก็มีเหตุผล
อย่างที่ Terence ว่าไว้ ห่วงโซ่ที่อ่อนที่สุดอาจถูกเจาะได้จริง และนั่นเป็นเหตุผลว่าทำไมเราจึงต้องมีหลายชั้นป้องกัน
มีกรณีจริงไม่นานมานี้ที่เจ้าหน้าที่ helpdesk รีเซ็ตรหัสผ่านของลูกค้าโดยไม่ตรวจสอบใด ๆ
แม้จะมีเทคโนโลยี security ที่แข็งแรงอย่าง VPN และ 2FA แต่ห่วงโซ่ที่อ่อนที่สุดอย่าง 'การกู้คืนบัญชี' เพียงจุดเดียวก็ทำให้ทั้งระบบล้มเหลว
ภายในยังมีชั้นเพิ่มเติมที่ช่วยตรวจจับและสกัดผู้บุกรุกได้ภายใน 3 ชั่วโมง แต่นั่นคือ 'การลดความเสียหาย' ไม่ใช่ 'การป้องกันล่วงหน้า'
สุดท้ายแล้วต้องมีหลายชั้นจึงจะจำกัดความเสียหายได้
ช่วงหลังในวงการ infosec เองก็เปลี่ยนโฟกัสจาก "ป้องกัน 100%" ไปสู่ "ลดผลกระทบ"
เพราะป้องกันความเสี่ยงทุกอย่างได้ยาก จึงเปลี่ยนมาเน้นลดความเสี่ยง ลดพื้นผิวโจมตี และลดระดับความไว้วางใจแทน
ผมไม่ใช่ผู้เชี่ยวชาญด้าน security เลย แต่เคยได้ยินมาว่า "พื้นผิวโจมตีที่ถูกลดลงอย่างที่สุด และการใช้โปรโตคอลโอเพนซอร์สที่ผ่านการตรวจสอบแล้ว" คือแนวป้องกันที่ดีที่สุด
เลยสงสัยว่าสิ่งนี้ต่างจากสิ่งที่คุยกันตรงไหน
แค่เลือกอุปมาได้ไม่ค่อยเหมาะเท่านั้นเอง
คำว่า "ห่วงโซ่ที่อ่อนที่สุด" จะถูกต้องเมื่อผู้โจมตีต้องฝ่าหลายขั้นตอนที่เรียงกัน
แต่ถ้ามีหลายชั้นอยู่ในระดับเดียวกัน การโจมตีส่วนที่อ่อนที่สุดย่อมสมเหตุสมผล
อย่างที่กังวลไว้ มันเลยเปิดช่องให้ตีความกำกวมได้จริง
ผมมองว่าการโจมตีก็เป็นอีกชั้นหนึ่งของการป้องกันเหมือนกัน
ตามสำนวนที่ว่า 'การโจมตีที่ดีที่สุดคือการป้องกันที่ดีที่สุด'
ใน cybersecurity นั้น red team กับ blue team เป็นสองทีมที่มีอำนาจใกล้เคียงกัน
แต่ในงานพัฒนาซอฟต์แวร์ ผมรู้สึกว่าอุปมานี้ออกจะเกินจริงไปหน่อย
tests ก็เป็นโค้ด และก็มีบั๊กได้
มันเลยเกิดความย้อนแย้งแบบ "Who polices the police?" ขึ้นมา
ประโยคภาษาอังกฤษเล่นความหมายด้วยการซ้ำคำ คล้าย Buffalo sentence
ทำให้นึกถึงแนวคิด mental mode ของ John Cleese เรื่อง "โหมดเปิด vs โหมดปิด"
ตอนคิดไอเดียก็เปิดให้กว้างที่สุดเพื่อให้มีความหลากหลาย
แล้วค่อยเปลี่ยนเป็นโหมดปิดภายหลังเพื่อคัดไอเดียแย่ ๆ ทิ้ง และพัฒนาเฉพาะอันที่ดี
นักเขียนแทบทุกสาขาก็มักมีบรรณาธิการ
การออกแบบเกมการ์ด Magic: the Gathering ก็คล้ายกัน โดยทีมออกแบบจะทำดราฟต์เซ็ตขึ้นมาก่อน แล้วส่งต่อให้ทีมพัฒนาที่แยกขาดจากกันโดยสิ้นเชิงไปตรวจสอบ
ถ้ามีตัวอย่างความร่วมมือแบบนี้อีกก็อยากฟัง
ผมกลับคิดว่าความจริงตรงข้ามกับโพสต์นี้
LLM เก่งมากเวลาทำ draft แรกอย่างรวดเร็ว และมนุษย์ที่ได้รับการฝึกฝนมาดีเหมาะกับการตรวจทานผลลัพธ์ของ LLM แบบวิพากษ์มากกว่า
ดังนั้น LLM จึงเหมาะกับบทบาท blue team ส่วนมนุษย์เหมาะกับ red team มากกว่า
ดูเหมือน Tao กำลังพูดถึงสถานการณ์สุดขั้วแบบนั้นอยู่
ช่วงหลังได้ลองใช้โมเดลและ workflow แบบ agentic แล้วรู้สึกว่า
agent พวกนี้จะฉายศักยภาพที่สุดเมื่อใช้ไม่ใช่แค่เขียนโค้ด แต่รวมถึงการทดสอบ การบริหาร และแม้กระทั่งบทบาทด้าน management ด้วย
นักพัฒนาจะกลายเป็นผู้จัดการหรือผู้กำกับดูแลรูปแบบหนึ่ง
อยู่ในตำแหน่งที่คอยกำกับทั้งการวางแผนงานทั้งหมด (การเขียน prompt, การจัดขอบเขตงาน), การเขียน tests และการเขียนโค้ด
แม้ปริมาณการรีวิวจะเพิ่มขึ้นมาก แต่พอได้ทำหน้าที่ red team เองเพื่อตรวจว่ามันพังน้อยลงไหม ก็กลับรู้สึกว่าควบคุมได้มากขึ้น
มุมมองนี้น่าสนใจมาก
ในโลกธุรกิจก็อาจแบ่งเป็น ‘blue team’ (อุตสาหกรรมโครงสร้างพื้นฐานทางสังคม: ไฟฟ้า น้ำมัน โทรคมนาคม ซอฟต์แวร์ การเงิน ฯลฯ) กับ ‘red team’ (อุตสาหกรรมมูลค่าเพิ่ม: ร้านอาหาร ค้าปลีกเฉพาะทาง สินค้าฟุ่มเฟือย การท่องเที่ยว ฯลฯ) ได้เหมือนกัน
ในเชิงเศรษฐกิจ ฝั่ง blue team สำคัญกว่ามาก เพราะอุตสาหกรรมเหล่านี้เป็นฐานของเศรษฐกิจทั้งหมด มีอุปสงค์สูง และทีมนี้ต้องลดความผิดพลาดให้ได้มากที่สุด
ส่วนอุตสาหกรรมฝั่ง red team ถึงไม่มีเศรษฐกิจก็ยังเดินต่อได้ แต่ยิ่งมีมากก็ยิ่งช่วยยกระดับคุณภาพโดยรวม
ในตัวอย่างของ Tao เอง การที่วิศวกรซอฟต์แวร์ได้เงินมากกว่า QA และการที่การเขียน proof ถูกมองว่ามีมูลค่าทางเศรษฐกิจมากกว่าการตรวจพิสูจน์ ก็เป็นโครงสร้างแบบเดียวกัน
ตอน Sam Altman หาเงินมาฝึก LLM เขาก็ต้องย้ำว่า "เราใช้งานได้จริงแบบ blue team" ถึงจะระดมทุนง่าย และนั่นก็ส่งผลต่อ narrative ของสื่อทั้งหมด
ทั้งที่จริงแล้วมันเหมาะกับการใช้งานแบบ red team มากกว่า แต่เพราะต้องชูเรื่องการคืนทุน บริษัทต่าง ๆ จึงจะผลักดัน LLM ไปใช้กับงานแบบ blue team เท่านั้น
Google Glasses, VR และอุปกรณ์ wearable ก็เป็นแพตเทิร์นคล้ายกัน
สิ่งเหล่านี้เป็นเทคโนโลยีแบบ red team ที่มีประโยชน์ในอุตสาหกรรมเฉพาะทาง แต่เพราะสร้าง ecosystem หรือรายได้มหาศาลไม่ได้ จึงไม่เป็นที่สนใจในมุมมองของทุน
(ผมอยู่ Microsoft)
ผมรันการตรวจสอบ red team แบบอัตโนมัติด้วย azure-ai-evaluation SDK กับตัวอย่าง RAG โดยตรง
ในที่นี้จะมี adversarial LLM ที่ตั้งใจออกนอกกรอบกับแพ็กเกจ pyrit มาผสานกัน เพื่อสร้างคำถามประหลาด ๆ โยนใส่แอปโดยอัตโนมัติ และยังแปลงคำถามด้วย base64, Caesar cipher, urldecode ฯลฯ ด้วย
ผลลัพธ์จริงค่อนข้างน่าสนใจ และผมเห็นด้วยว่า LLM มีประโยชน์กับงาน red team มากพอสมควร
วิดีโอเดโมบน YouTube
(ขออภัยหากโทนเสียงดังไปหน่อย ถ่ายในสถานที่แปลก ๆ)