AI vs AI ในโลกไซเบอร์: กลยุทธ์การป้องกันสำหรับทีมขนาดเล็กและแผนปฏิบัติการ 30 วัน

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

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

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

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

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

ARTEX ซึ่งเราใช้ในการตรวจสอบ Penetration Testing เป็นแพลตฟอร์มที่ AI Agent ใช้ควบคุมเครื่องมือเพื่อตรวจสอบเป้าหมายและรายงานผล ใน บทความการตรวจสอบที่เผยแพร่ไปแล้ว เราได้รายงานว่าเมื่อใช้งานร่วมกับ GLM เราสามารถยืนยันการรันโค้ดบนเซิร์ฟเวอร์สำหรับจุดอ่อน 2 ประเภทที่เตรียมไว้ในแอปพลิเคชัน PHP ที่เราสร้างขึ้นเองได้

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

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

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

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

จากการประเมินของบริษัท AI รับหน้าที่ดำเนินการปฏิบัติการถึง 80-90% โดยจำเป็นต้องมีการแทรกแซงจากมนุษย์เพียง 4-6 จุดตัดสินใจที่สำคัญต่อการปฏิบัติการแต่ละครั้ง สัดส่วนนี้เป็นการประเมินการแบ่งงานในการปฏิบัติการดังกล่าว ไม่ใช่อัตราความสำเร็จของการโจมตี และไม่ใช่การประเมินว่าการโจมตีทุกรูปแบบจะสามารถทำระบบอัตโนมัติในสัดส่วนเดียวกันได้

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

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

เมื่อนำกรณีศึกษามาปรับใช้กับการออกแบบการป้องกัน คุณสามารถจัดลำดับความสำคัญได้ 3 ประการ ดังนี้ ซึ่งเป็นสิ่งที่บทความนี้แนะนำ:

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

รายงาน M-Trends 2026 ของ Mandiant ระบุว่า จากการตรวจสอบการละเมิดความปลอดภัยทั่วโลกของบริษัท พบว่าช่องทางเริ่มต้นในการบุกรุกมาจากการใช้ประโยชน์จากช่องโหว่ (Vulnerability) 32% และการฟิชชิงทางโทรศัพท์ 11% ทั้งนี้ นี่เป็นรายละเอียดจากกลุ่มตัวอย่างที่บริษัทตรวจสอบ ไม่ใช่สถิติของการโจมตีด้วย AI เพียงอย่างเดียว M-Trends 2026

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

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

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

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

OWASP ให้ความสำคัญกับการใช้ไลบรารีหรือ API ทดแทนการเรียกใช้ OS command โดยตรงเป็นอันดับแรก แม้ในกรณีที่จำเป็นต้องเรียกใช้ การแยกอาร์กิวเมนต์เพียงอย่างเดียวก็ไม่เพียงพอที่จะทำให้อินพุตปลอดภัย แต่ต้องใช้การตรวจสอบคำสั่งและอาร์กิวเมนต์ควบคู่กันไปด้วย แนวทางการป้องกัน OS Command Injection

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

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

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

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

ตารางต่อไปนี้เป็นตัวอย่างการตัดสินใจสำหรับทีมขนาดเล็ก นี่ไม่ใช่ตารางที่แสดงกำหนดการแก้ไขอย่างเป็นทางการหรือข้อกำหนดทางกฎหมายที่ตายตัว

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

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

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

• ไม่ใช้ผู้ดูแลระบบ (Administrator) เป็นผู้ใช้งานแอปพลิเคชัน และจำกัดสิทธิ์ให้เหลือเพียงเท่าที่จำเป็นต่อการปฏิบัติงานเท่านั้น
• แยกข้อมูลรับรองตามวัตถุประสงค์การใช้งาน และเพิกถอนกุญแจหรือบัญชีที่ไม่ได้ใช้งานแล้ว
• จำกัดการสื่อสารจากเซิร์ฟเวอร์ออกสู่ภายนอก โดยระบุปลายทางและวัตถุประสงค์ที่จำเป็นให้ชัดเจน
• ตั้งค่าการยืนยันตัวตนแบบหลายปัจจัย (Multi-Factor Authentication: MFA) สำหรับผู้ดูแลระบบ และกำหนดให้มีการยืนยันตัวตนของบุคคลนั้นๆ ในกรณีที่มีการตั้งค่าการยืนยันตัวตนใหม่หรือเพิ่มสิทธิ์

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

ในด้านการตรวจจับ นอกจากการจัดเก็บ Log แล้ว ให้พิจารณาสิ่งต่อไปนี้เป็นรายการเฝ้าระวัง เนื่องจากพฤติกรรมบางอย่างอาจเป็นเรื่องปกติในบางสภาพแวดล้อม จึงไม่ควรด่วนสรุปว่าเป็นการบุกรุกเพียงอย่างเดียว แต่ควรตรวจสอบเทียบกับงานที่ได้รับอนุญาตด้วย

1. กระบวนการของ Web App เรียกใช้ Shell หรือกระบวนการลูก (Child Process) ที่ไม่คาดคิด
2. มีการสร้างไฟล์ปฏิบัติการหรือไฟล์ตั้งค่าที่ไม่คาดคิดในปลายทางที่อัปโหลด
3. มีการเพิ่มผู้ดูแลระบบ หรือมีการเปลี่ยนแปลงสิทธิ์สำคัญ
4. มีการสื่อสารไปยังปลายทางที่ไม่คุ้นเคย หรือมีการส่งข้อมูลจำนวนมากเกิดขึ้น

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

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

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

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

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

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

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

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

นอกเหนือจากข้อมูลติดต่อของแต่ละสาขาแล้ว ให้กำหนดผู้ที่มีอำนาจตัดสินใจในการแยกส่วน (Isolation) การกลับมาใช้งานใหม่ (Resumption) และการติดต่อภายนอกสำหรับทั้งองค์กร ประเทศญี่ปุ่นและประเทศไทยมีเวลาต่างกัน 2 ชั่วโมง จึงควรจัดทำรายการวิธีการติดต่อทั้งผู้ติดต่อหลัก ผู้ติดต่อสำรอง และผู้รับเหมาดูแลระบบ โดยครอบคลุมถึงช่วงเวลากลางคืนและวันหยุดของทั้งสองสาขา

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

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

• เวลาที่พบพร้อมระบุเขตเวลา (Time zone) และเวลาที่เกิดเหตุเท่าที่ทราบ
• ระบบที่เกี่ยวข้อง ความผิดปกติที่ตรวจพบ และงานที่คาดว่าจะได้รับผลกระทบ
• การดำเนินการที่ทำไปแล้ว เช่น การแยกส่วนหรือการหยุดระบบ และผู้รับผิดชอบ
• สถานที่จัดเก็บไฟล์บันทึก (Log) หรือหลักฐานต้นฉบับ และประเด็นที่ยังไม่ได้ตรวจสอบ

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

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

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

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

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

สำหรับการนำไปใช้งาน ให้เลือกจากงานที่มนุษย์ไม่สามารถอ่านการแจ้งเตือนได้ทั้งหมด หรือเป็นงานที่ต้องใช้เวลาในการตรวจสอบผลกระทบ แทนที่จะเลือกจาก "งานที่สามารถใช้ AI ได้"

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

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

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

บันทึก (log) โค้ด และอีเมลที่ AI อ่านนั้นมีเนื้อหาที่ผู้โจมตีสามารถเขียนแทรกเข้าไปได้ ปัญหาที่คำสั่งซึ่งถูกฝังอยู่ในเนื้อหาเหล่านั้นสามารถชี้นำการตัดสินใจหรือการทำงานของ AI ได้ เรียกว่า Prompt Injection

Google GTIG รายงานว่าพบข้อความที่มุ่งเป้าให้ AI Security Scanner วิเคราะห์ล้มเหลวหรือข้ามการทำงานไป ซึ่งถูกฝังอยู่ในมัลแวร์ที่เกี่ยวข้องกับ TeamPCP (UNC6780) ทั้งนี้ นี่เป็นการวิเคราะห์เจตนาของผู้โจมตี ไม่ใช่การพิสูจน์ว่าการหลบเลี่ยงการตรวจจับของสแกนเนอร์ทุกตัวจะประสบความสำเร็จเสมอไป รายงานของ GTIG

OWASP ระบุว่ายังไม่ชัดเจนว่ามีวิธีป้องกัน Prompt Injection ที่ได้ผลแน่นอนหรือไม่ โดยได้เสนอมาตรการรับมือแบบผสมผสาน เช่น หลักการให้สิทธิ์น้อยที่สุด (Least Privilege), การอนุมัติโดยมนุษย์ และการแยกข้อมูลนำเข้าจากภายนอกออกจากกัน สรุปโดย OWASP

ในการนำไปใช้งาน ให้ตรวจสอบ 5 ข้อต่อไปนี้:

1. เก็บข้อมูลต้นฉบับและขอบเขตการประมวลผลไว้: ตรวจสอบจำนวนรายการที่ส่งให้ AI จำนวนที่ประมวลผลจริง และช่วงเวลาที่เกี่ยวข้องผ่านทางโปรแกรม เพื่อค้นหาการข้ามขั้นตอนหรือความล้มเหลวในการทำงาน เนื่องจากจำนวนที่ตรงกันไม่ได้หมายความว่าเนื้อหาจะถูกต้องเสมอไป จึงควรมีการสุ่มตรวจด้วย
2. ควบคุมสิทธิ์จากภายนอก AI: จำกัดการดำเนินการและเป้าหมายที่สามารถทำได้ผ่านแอปพลิเคชันหรือกลไกการให้สิทธิ์ การสั่งห้ามผ่านคำสั่ง (Instruction) เพียงอย่างเดียวไม่ถือเป็นการจำกัดสิทธิ์
3. จำกัดขอบเขตการอ่านและปลายทางที่ส่งข้อมูล: ห้ามส่งข้อมูลรับรอง (Credentials) หรือข้อมูลส่วนบุคคลที่ไม่จำเป็น และตรวจสอบเงื่อนไขการส่งข้อมูลไปยังบริการ AI ภายนอก แม้จะเป็นการอ่านอย่างเดียว ก็ต้องตรวจสอบช่องทางที่อาจนำข้อมูลออกไปได้
4. แยกข้อมูลนำเข้าจากภายนอกออกจากคำสั่ง: ออกแบบการทดสอบโดยส่งบันทึกหรืออีเมลในฐานะข้อมูลที่ไม่น่าเชื่อถือ และทำให้ AI ไม่ปฏิบัติตามคำสั่งที่แฝงอยู่ในนั้น ทั้งนี้ การแยกข้อมูลออกจากกันเพียงอย่างเดียวไม่ถือว่าเป็นการป้องกันที่สมบูรณ์
5. กำหนดการทำงานเมื่อเกิดความล้มเหลวและการส่งต่องานให้มนุษย์: หากข้อมูลไม่เพียงพอ รูปแบบไม่ถูกต้อง หรือเกิด Time-out ให้คงสถานะว่ายังไม่ได้ประมวลผลและส่งต่อให้มนุษย์จัดการ ห้ามตั้งค่าให้ระบบสรุปเองว่าเป็น "ปกติ" หรือ "ดำเนินการเสร็จสิ้น"

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

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

ตรวจสอบความจำเป็นของ AI ขอบเขตการตรวจสอบ และขั้นตอนการเริ่มต้นใช้งาน

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

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

ในช่วงสัปดาห์แรก ให้ตรวจสอบ 4 หัวข้อต่อไปนี้:

1. จัดทำรายการสินทรัพย์ที่เปิดเผยต่อสาธารณะและผู้รับผิดชอบ
2. ตรวจสอบว่ามีช่องโหว่ที่ถูกนำไปใช้ในทางที่ผิด (Exploited Vulnerabilities) หรือไม่
3. ตรวจสอบการยืนยันตัวตนแบบหลายปัจจัย (MFA) ของผู้ดูแลระบบ และข้อมูลติดต่อในกรณีฉุกเฉิน
4. ทดสอบว่าสามารถกู้คืนข้อมูลที่จำเป็นจากข้อมูลสำรองได้หรือไม่

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

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

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

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

เงื่อนไขของการทดลองสามารถดูได้ที่ การตรวจสอบ RCE ด้วย ARTEX×GLM กลไกการทำงานของเครื่องมือสามารถดูได้ที่ คำอธิบายเกี่ยวกับ Strix, Cairn และ Hermes และภาพรวมของความเสี่ยงที่เกี่ยวข้องสามารถดูได้ที่ แนวโน้มล่าสุดด้านความปลอดภัยทางไซเบอร์ของ AI