Strix, Cairn, Hermes คืออะไร? กลไกการทำงานและความเสี่ยงของเครื่องมือ AI Security

Strix, Cairn, และ Hermes เป็นเครื่องมือที่ใช้ AI ในการตรวจสอบช่องโหว่ การดำเนินการ และการจัดการความต่อเนื่องของงาน ซึ่งหากทำความเข้าใจว่าเครื่องมือเหล่านี้ไม่ใช่ผลิตภัณฑ์ที่แข่งขันกันด้วยฟังก์ชันเดียวกัน แต่เป็น AI agent ที่มีบทบาทแตกต่างกัน ก็จะเห็นถึงความแตกต่างของแต่ละตัวได้ชัดเจนยิ่งขึ้น

หลายท่านอาจรู้จักเครื่องมือทั้ง 3 นี้จาก รายงานข่าวของ Weekly ASCII สิ่งที่องค์กรควรให้ความสำคัญมากกว่าความใหม่ของชื่อ คือ "AI สามารถดำเนินการตามเนื้อหาที่ตัดสินใจได้ด้วยสิทธิ์ระดับใด" ในบทความนี้ เราจะเจาะลึกถึงการออกแบบของเครื่องมือแต่ละตัว พร้อมอธิบายวิธีอ่านตัวเลขจากกรณีการใช้งานในทางที่ผิด รวมถึงเกณฑ์การตัดสินใจสำหรับองค์กรในการนำไปปรับใช้เพื่อการป้องกันและการตรวจสอบ

สามารถแบ่งออกได้เป็น 3 บทบาทหลัก ได้แก่ การสำรวจ (Exploration), การลงมือทำเพื่อให้บรรลุเป้าหมาย (Execution), และการบริหารจัดการอย่างต่อเนื่อง (Continuous Management) อย่างไรก็ตาม ฟังก์ชันการทำงานจริงอาจมีความคาบเกี่ยวกันอยู่บ้าง

จากการตรวจสอบของ Gambit Security พบว่า Strix ถูกใช้ในการค้นหาช่องโหว่, Cairn ถูกใช้ในการเจาะระบบ และ Hermes ถูกใช้ในการเริ่มงานและจัดการกิจกรรมโดยรวม ทั้งนี้เป็นการแบ่งหน้าที่ในกรณีดังกล่าวเท่านั้น ไม่ใช่การจำกัดฟังก์ชันการทำงานของผลิตภัณฑ์แต่ละตัวแต่อย่างใด รายงานฉบับแรกของ Gambit

ต่อไปนี้คือการสรุปฟังก์ชันการทำงานตามเอกสารที่เปิดเผยต่อสาธารณะ โดยแถวของ Cairn อ้างอิงถึง oritera/Cairn เวอร์ชันสาธารณะ ซึ่งยังไม่ได้รับการยืนยันว่าเป็นตัวเดียวกับที่ใช้ในเหตุการณ์จริงหรือไม่

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

แม้ว่าโมเดล AI จะสามารถคิดวิเคราะห์ขั้นตอนถัดไปจากข้อความได้ แต่สิ่งนั้นไม่ได้ทำให้เบราว์เซอร์หรืออุปกรณ์ทำงานได้ด้วยตัวเอง จำเป็นต้องมีซอฟต์แวร์ที่คอยเชื่อมโยงผลลัพธ์จากโมเดลเข้ากับการเรียกใช้เครื่องมือ (Tool calling) ส่งผลลัพธ์กลับ และดำเนินการตัดสินใจในขั้นตอนถัดไป กลไกที่สนับสนุนการทำงานนี้เรียกอีกอย่างว่า "Harness" เอกสารอย่างเป็นทางการของ Strix ได้แสดงการออกแบบที่รวมเบราว์เซอร์ พร็อกซีสำหรับตรวจสอบการสื่อสาร HTTP และอุปกรณ์ต่างๆ เข้ากับเอเจนต์ เอกสารอย่างเป็นทางการของ Strix

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

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

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

สำหรับแนวคิดในการแบ่งงานกันทำ สามารถดูข้อมูลเพิ่มเติมได้ที่คำอธิบายเรื่อง Agent Orchestration

จุดเด่นของ Strix คือการเชื่อมโยงการค้นพบจุดที่น่าสงสัยเข้ากับการตรวจสอบว่าปัญหานั้นเกิดขึ้นจริงหรือไม่ โดยเปิดให้ใช้งานในฐานะเครื่องมือทดสอบการเจาะระบบ (Penetration Testing Tool) สำหรับนักพัฒนาและผู้ดูแลด้านความปลอดภัย

Strix มีฟีเจอร์สำหรับตรวจสอบพฤติกรรมของแอปพลิเคชันขณะทำงาน นอกเหนือไปจากการวิเคราะห์ด้วยการอ่านโค้ด โดยในเอกสารอย่างเป็นทางการได้อธิบายถึงโครงสร้างที่เอเจนต์ผู้เชี่ยวชาญจะทำงานร่วมกันเพื่อแบ่งปันสิ่งที่ค้นพบ และยืนยันช่องโหว่ผ่านการพิสูจน์แนวคิดที่เรียกว่า PoC เอกสารอย่างเป็นทางการของ Strix

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

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

ที่เก็บข้อมูลอย่างเป็นทางการของ Strix มีฟังก์ชันการทำงานที่รองรับการชี้แจงพร้อมหลักฐาน การเสนอการแก้ไข การจัดทำรายงาน และการรวมเข้ากับกระบวนการพัฒนา อย่างไรก็ตาม คำอธิบายผลิตภัณฑ์เหล่านี้ไม่ใช่การรับประกันแบบอิสระว่าจะไม่มีการมองข้ามหรือการตรวจจับที่ผิดพลาดในทุกสภาพแวดล้อม ที่เก็บข้อมูลอย่างเป็นทางการของ Strix

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

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

สำหรับการประเมินความสามารถในการวินิจฉัยของ AI สามารถดูเพิ่มเติมได้ที่ คำอธิบายเกี่ยวกับ CyberGym และการประเมินความปลอดภัยของ AI

Cairn เป็นเบาะแสที่ช่วยให้เข้าใจกลไกการเลือกการสำรวจครั้งถัดไปจากข้อมูลที่ได้รับ อย่างไรก็ตาม ในรายงานของ Gambit ไม่มีการระบุเวอร์ชันที่ใช้งานหรือที่เก็บข้อมูล (repository) จึงไม่สามารถสรุปได้ว่าการใช้งานในเหตุการณ์ดังกล่าวกับโปรเจกต์สาธารณะ oritera/Cairn ที่อธิบายไว้ ณ ที่นี้เป็นสิ่งเดียวกัน รายงานฉบับเต็มของ Gambit

ที่เก็บข้อมูลสาธารณะ oritera/Cairn วางตำแหน่งตัวเองเป็นเครื่องมือค้นหาปริภูมิสถานะ (State Space Search Engine) แบบอเนกประสงค์ โดยมีการทดสอบการเจาะระบบ (Penetration Testing) เป็นขอบเขตการตรวจสอบเริ่มต้น หัวใจสำคัญคือกระดานสนทนาที่ใช้ร่วมกัน ซึ่งจัดการข้อมูล Fact ที่เป็นผลการตรวจสอบ, Intent ที่เป็นแนวทางการค้นหาที่ยังไม่ได้ดำเนินการ และ Hint ที่เป็นข้อมูลประกอบการตัดสินใจจากมนุษย์ โดยที่เวิร์กเกอร์ (Worker) จะไม่มีหน้าที่ตายตัว แต่จะอ่านสถานะที่แชร์ไว้เพื่อทำการค้นหาและเขียนผลลัพธ์กลับลงไป ที่เก็บข้อมูลสาธารณะ Cairn

การออกแบบนี้แตกต่างจากวิธีการสร้างรายการตรวจสอบยาวๆ แล้วค่อยๆ ทำไปตามลำดับ เพราะหากสมมติฐานเปลี่ยนไประหว่างการทำงาน สิ่งที่ต้องตรวจสอบต่อไปก็จะเปลี่ยนไปด้วยเช่นกัน

ตัวอย่างเช่น ในการตรวจสอบภายในที่ได้รับอนุญาต หากพบว่าฟังก์ชันหนึ่งถูกยกเลิกไปแล้ว เหตุผลที่จะต้องตรวจสอบฟังก์ชันนั้นต่อไปก็จะลดน้อยลง หากสามารถแชร์ผลการตรวจสอบได้ ผู้ปฏิบัติงานคนอื่นก็จะสามารถใช้สมมติฐานเดียวกันได้ นี่เป็นเพียงตัวอย่างเพื่อให้เข้าใจกลไกการทำงานเท่านั้น ไม่ใช่การแสดงผลลัพธ์จากการวินิจฉัยจริงแต่อย่างใด

เอกสารการออกแบบของ Cairn จัดให้การทดลองเบื้องต้น การตัดสินใจอ่านสถานการณ์ใหม่ และการสำรวจเฉพาะทางเป็นงาน (Task) แยกต่างหาก โดยมี Dispatcher ทำหน้าที่จัดสรรงานและจัดการการดำเนินการ ส่วน Worker ทำหน้าที่ตัดสินใจสถานการณ์และสำรวจเฉพาะทาง การออกแบบ Dispatcher ของ Cairn

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

Cairn เวอร์ชันสาธารณะระบุไว้อย่างชัดเจนว่าไม่มี Sandbox สำหรับการดำเนินการในเครื่อง (Local execution) ดังนั้นวิธีการจำกัดสิทธิ์ของสภาพแวดล้อมการทำงานจึงเป็นประเด็นสำคัญในการตัดสินใจนำไปใช้งาน คลังเก็บข้อมูลสาธารณะของ Cairn

Hermes Agent คือเอเจนต์อเนกประสงค์ที่เผยแพร่โดย Nous Research ด้วยความสามารถในการจดจำและทักษะเฉพาะตัว ทำให้สามารถทำงานต่อเนื่องได้มากกว่าการสนทนาแบบครั้งเดียว ซึ่งนำไปสู่ความเข้าใจในบทบาทการเป็นผู้จัดการ Hermes Official Repository

หน่วยความจำถาวร (Persistent Memory) ของ Hermes เป็นกลไกสำหรับจัดเก็บประเด็นสำคัญที่ต้องใช้ข้ามเซสชัน ในเอกสารอย่างเป็นทางการอธิบายไว้ว่า เป็นการแยกข้อมูลหน่วยความจำเกี่ยวกับสภาพแวดล้อมออกจากข้อมูลของผู้ใช้งาน และจะถูกโหลดขึ้นมาเมื่อเริ่มต้นเซสชัน ส่วนรายละเอียดความเป็นมาในอดีตนั้นจะใช้วิธีการค้นหาจากประวัติเซสชันมาช่วยเสริม หน่วยความจำถาวรของ Hermes

สกิล (Skills) คือเอกสารขั้นตอนหรือความรู้ที่จะถูกโหลดขึ้นมาเมื่อจำเป็น โดยไม่ได้โหลดเนื้อหาทั้งหมดทุกครั้ง แต่ใช้โครงสร้างที่เริ่มจากชื่อและบทสรุปเพื่อเข้าถึงเอกสารที่ต้องการ ข้อกำหนดด้านสกิลของ Hermes

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

ที่เก็บข้อมูลอย่างเป็นทางการของ Hermes ยังระบุถึงการทำงานตามกำหนดเวลาและการมอบหมายงานให้กับตัวแทนย่อย (Sub-agent) อีกด้วย ฟังก์ชันเหล่านี้สามารถนำไปใช้กับการตรวจสอบตามระยะเวลาหรืองานที่ต้องทำซ้ำๆ ได้ การมองว่า Hermes เป็นผลิตภัณฑ์สำหรับการโจมตีเพียงอย่างเดียวนั้นถือว่าไม่เหมาะสม ที่เก็บข้อมูลอย่างเป็นทางการของ Hermes

ในเชิงการปฏิบัติ สิ่งสำคัญคือการพิจารณาว่าจะคงสิ่งใดไว้ในระบบที่ทำงานอย่างต่อเนื่อง แม้ว่าเป้าหมายหรือการดำเนินการที่ได้รับอนุญาตจากการตรวจสอบเมื่อเดือนที่แล้วจะถูกบันทึกไว้ในทักษะ (Skill) แต่ก็ไม่ได้หมายความว่าการอนุญาตนั้นจะยังคงมีผลในเดือนนี้ การที่ขั้นตอนการทำงานมีประโยชน์กับการที่การดำเนินการนั้นได้รับอนุมัติเป็นคนละประเด็นกัน

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

เอกสารอย่างเป็นทางการของ Hermes ได้อธิบายถึงกลไกที่ต้องขออนุมัติก่อนการเรียกใช้คำสั่งที่เป็นอันตราย รวมถึงการตั้งค่าเพื่อข้ามขั้นตอนการยืนยันการอนุมัติ อย่างไรก็ตาม ข้อจำกัดบางประการ เช่น รายการห้าม (Deny list) ที่เปิดใช้งานตลอดเวลาจะยังคงมีผลอยู่ ในระหว่างการนำไปใช้งาน โปรดตรวจสอบทั้งการตั้งค่าการอนุมัติและข้อจำกัดที่ยังคงมีอยู่ เอกสารความปลอดภัยของ Hermes

ประเด็นสำคัญของกรณีศึกษานี้คือ ภาระในการดำเนินการสำรวจและลงมือปฏิบัติอย่างต่อเนื่องอาจเปลี่ยนแปลงไปได้ด้วย AI ตัวเลขความเสียหายและค่าใช้จ่ายจำเป็นต้องอ่านโดยพิจารณาจากกลุ่มเป้าหมายที่สำรวจและเงื่อนไขในการรวบรวมข้อมูลที่สอดคล้องกัน ตามรายงานของ Gambit ระบุว่า ในช่วงวันที่ 10-15 กันยายน 2026 มีการเริ่มโครงการโจมตี 105 โครงการ และมีบริษัทอย่างน้อย 27 แห่งถูกละเมิดในรูปแบบใดรูปแบบหนึ่ง

ตัวเลขเฉลี่ย 25.46 ดอลลาร์ที่ Gambit ระบุไว้ คือการรวบรวมค่าใช้จ่ายจากฝั่งผู้โจมตีเอง โดยเป็นค่าเฉลี่ยต่อการสแกน 1 ครั้ง จากการสแกนที่เสร็จสมบูรณ์ทั้งหมด 101 ครั้ง ซึ่งมีช่วงราคาตั้งแต่เป้าหมายที่ถูกที่สุด 3.13 ดอลลาร์ ไปจนถึงเป้าหมายที่แพงที่สุด 79.31 ดอลลาร์ ตัวเลขนี้เป็นการรวบรวมโดยเน้นที่ค่าธรรมเนียมการใช้งานโมเดล ไม่ใช่ต้นทุนรวมต่อการบุกรุกสำเร็จ 1 ครั้ง และไม่ใช่ราคาของบริการที่มีวางจำหน่ายทั่วไป ในการรวบรวมข้อมูลอีกชุดหนึ่ง พบค่าใช้จ่ายในการใช้งานโมเดลเป็นเวลา 4 สัปดาห์อยู่ที่ 7,005.71 ดอลลาร์ ตามบันทึกของบัญชี และมีการประเมินว่าค่าใช้จ่ายรวมถึงกิจกรรมหลังจากนั้นจะอยู่ที่ประมาณ 1.2 หมื่นถึง 1.8 หมื่นดอลลาร์ รายงานฉบับเต็มของ Gambit

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

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

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

ดังนั้น จึงไม่สามารถสรุปจากกรณีนี้เพียงกรณีเดียวได้ว่า "ใครก็ตามสามารถบุกรุกบริษัทใดก็ได้เพียงแค่ให้คำสั่งสั้นๆ" อย่างไรก็ตาม ในเมื่อมีกลไกที่สามารถอ่านผลลัพธ์ระหว่างทาง เลือกแนวทางใหม่ และดำเนินการต่อได้ ฝ่ายป้องกันจึงไม่สามารถตั้งสมมติฐานได้ว่าผู้บุกรุกจะยอมแพ้หากทำพลาดเพียงครั้งเดียว นี่คือข้อเสนอแนะเชิงปฏิบัติที่สามารถสรุปได้จากการออกแบบเครื่องมือแต่ละชนิดและกรณีศึกษาที่เกิดขึ้น

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

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

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

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

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

สำหรับการจัดลำดับความสำคัญในการแก้ไข สามารถอ้างอิง CISA KEV Catalog ซึ่งรวบรวมช่องโหว่ที่มีการยืนยันว่าถูกนำไปใช้โจมตีจริง สำหรับมาตรการรับมือการแก้ไขหน้าชำระเงิน สามารถอ้างอิง คำอธิบายเรื่องการจัดการและเฝ้าระวังสคริปต์ของ PCI SSC และสำหรับการเตรียมพร้อมด้านการกู้คืน สามารถอ้างอิง แนวทางปฏิบัติเรื่องการสำรองและตรวจสอบการกู้คืนของ CISA เป็นหลักฐานอ้างอิงได้

หากต้องการเรียบเรียงการเตรียมพร้อมรับมือกับการโจมตีด้วย AI ในวงกว้าง สามารถดูเพิ่มเติมได้ที่ บทความเรื่องการโจมตีทางไซเบอร์ด้วย AI และการป้องกันขององค์กร

OWASP ได้จัดประเภทปัญหาการให้ฟังก์ชันการทำงาน สิทธิ์ และความเป็นอิสระแก่ LLM agent มากเกินไปไว้ภายใต้หัวข้อ Excessive Agency โดยแนะนำให้จำกัดเครื่องมือและสิทธิ์เฉพาะที่จำเป็น และรวมกระบวนการอนุมัติโดยมนุษย์สำหรับการดำเนินการที่มีผลกระทบสูงไว้ด้วย คำอธิบายเรื่อง Excessive Agency ของ OWASP

สำหรับสิทธิ์ในการวินิจฉัย ควรพิจารณาแยกสิทธิ์ในการบันทึกรายงานออกจากสิทธิ์ในการแก้ไขเป้าหมาย นอกเหนือจากการระบุคำสั่งว่า "ห้ามแก้ไข" แล้ว จำเป็นต้องมีการกำหนดค่าที่ไม่ให้สิทธิ์ในการแก้ไขที่ไม่จำเป็นแก่ agent อีกด้วย

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

เอกสารความปลอดภัยอย่างเป็นทางการของ Hermes ได้ระบุไว้อย่างชัดเจนว่า ฟังก์ชันการป้องกันการจัดการไฟล์ไม่ใช่แซนด์บ็อกซ์ (Sandbox) ที่จะแยก agent ที่เป็นอันตรายหรือถูกบุกรุกออกจากระบบได้ เนื่องจากช่องทางการควบคุมเทอร์มินัลอาจเป็นคนละเส้นทางกัน เอกสารความปลอดภัยของ Hermes

เมื่อทำการแยกสภาพแวดล้อมการทำงาน ควรตรวจสอบโฟลเดอร์ที่ใช้ร่วมกัน การสื่อสารภายนอก และข้อมูลรับรอง (Credentials) ที่นำเข้ามาด้วย หากมีการมอบสิทธิ์ระดับสูงภายในสภาพแวดล้อมที่แยกออกมา ผลกระทบต่อส่วนที่สิทธิ์นั้นเข้าถึงได้ก็จะยังคงอยู่

หากจะใช้เพื่อวัตถุประสงค์ในการป้องกัน ก่อนอื่นให้เตรียมสภาพแวดล้อมสำหรับการตรวจสอบแบบจำกัดที่ได้รับอนุญาตเป็นลายลักษณ์อักษร เอกสารอย่างเป็นทางการของ Strix ยังระบุให้ทดสอบเฉพาะแอปพลิเคชันที่เป็นเจ้าของหรือเป้าหมายที่ได้รับอนุญาตอย่างชัดเจนเท่านั้น เอกสารอย่างเป็นทางการของ Strix

ก่อนการตรวจสอบ ให้กำหนดเป้าหมาย บัญชี ระยะเวลาดำเนินการ ขอบเขตที่สามารถเปลี่ยนแปลงได้ และเงื่อนไขการหยุดทำงานเมื่อเกิดความผิดปกติ นอกจากนี้ ให้เตรียมเวอร์ชัน การตั้งค่า และสิ่งที่ต้องการประเมินให้พร้อม

แม้จะรันเครื่องมือในเครื่อง (Local) แต่หากเป็นโครงสร้างที่ใช้โมเดลบนคลาวด์ ข้อมูลจะถูกส่งไปยังผู้ให้บริการ โปรดตรวจสอบขอบเขตการส่งข้อมูล การทำ Masking รวมถึงเงื่อนไขการจัดเก็บและการนำไปใช้เพื่อการเรียนรู้ของผู้ให้บริการ สำหรับรหัส (Code) เนื้อหาการสื่อสาร และข้อมูลรับรอง (Authentication credentials) ระหว่างการวินิจฉัย คำอธิบายสภาพแวดล้อมการทำงานของโมเดล Strix

ตัวชี้วัดที่ใช้ในการวัดผล ได้แก่ สัดส่วนของข้อชี้แนะที่สามารถทำซ้ำได้ (Reproduced findings), เวลาที่ใช้ในการตรวจสอบโดยมนุษย์, การมองข้ามปัญหาสำคัญ และเวลาที่ใช้ในการตรวจสอบซ้ำหลังจากแก้ไขแล้ว ทั้งนี้ นี่เป็นวิธีการประเมินที่แนะนำ ไม่ใช่ค่าที่วัดได้จริงจากเครื่องมือทั้ง 3 ชนิด การเตรียมแอปพลิเคชันสำหรับใช้สอนที่มีปัญหาที่ทราบอยู่แล้ว และเวอร์ชันที่แก้ไขปัญหาเหล่านั้นแล้ว จะช่วยให้สามารถแยกพิจารณาการตรวจพบและการยืนยันการแก้ไขออกจากกันได้

ควรเพิ่มการตรวจสอบการสั่งหยุดทำงานไว้ในการประเมินด้วย การตรวจสอบว่าเมื่อผู้รับผิดชอบสั่งให้หยุดทำงานแล้ว กระบวนการที่เครื่องปลายทาง (Terminal processing), ซับเอเจนต์ (Sub-agents) และงานตามกำหนดเวลา (Periodic jobs) จะหยุดทำงานหรือไม่นั้น จะช่วยให้สามารถระบุขอบเขตความรับผิดชอบหลังการนำไปใช้งานจริงได้อย่างเป็นรูปธรรม

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

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

ซอฟต์แวร์สาธารณะทั้ง 3 รายการมีใบอนุญาต (License) ที่แตกต่างกัน โดย Strix ใช้ Apache-2.0, Hermes ใช้ MIT และ oritera/Cairn เวอร์ชันสาธารณะใช้ AGPL-3.0 ใน README อย่างเป็นทางการของ Cairn ได้ระบุคำแนะนำไว้ว่า หากต้องการใช้งานในเชิงพาณิชย์หรือในสภาพแวดล้อมที่เป็นกรรมสิทธิ์ (Proprietary) โดยไม่ต้องการปฏิบัติตามข้อกำหนดของ AGPL จะต้องขอรับใบอนุญาตเชิงพาณิชย์แยกต่างหาก คำอธิบายใบอนุญาตของ Cairn

โปรดตรวจสอบเงื่อนไขในใบอนุญาตของแต่ละรีโพสิทอรีให้ชัดเจนก่อนนำไปใช้งาน

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

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

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

สำหรับการแบ่งหน้าที่และการตัดสินใจ สามารถดูรายละเอียดเพิ่มเติมได้ที่ การสร้างระบบทีม Red Team ภายในองค์กร

ในเอกสารที่เปิดเผยต่อสาธารณะ Strix มีจุดเด่นด้านการตรวจสอบและพิสูจน์ยืนยัน oritera/Cairn มีจุดเด่นด้านการสำรวจตามเป้าหมาย และ Hermes มีจุดเด่นด้านการจัดการอย่างต่อเนื่องโดยใช้ความจำและทักษะ บทบาทเหล่านี้มีความทับซ้อนกันอยู่ ดังนั้นจึงจำเป็นต้องแยกพิจารณาระหว่างเวอร์ชันและการตั้งค่าที่ถูกนำไปใช้ในเหตุการณ์จริง กับฟังก์ชันที่เปิดเผยต่อสาธารณะในปัจจุบัน โดยเฉพาะอย่างยิ่ง Cairn นั้นยังไม่ได้รับการยืนยันว่าการใช้งานในเหตุการณ์จริงกับเวอร์ชันที่เปิดเผยต่อสาธารณะเป็นสิ่งเดียวกันหรือไม่

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

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