สัมภาษณ์
โจนาธาน แซนเจอร์ Chief Technology Officer ที่ Check Point – สัมภาษณ์系列

โจนาธาน แซนเจอร์ Chief Technology Officer ที่ Check Point มีประสบการณ์ที่หายากในการรวมทหารอาวุโส ความเชี่ยวชาญด้าน AI และการเป็นผู้นำการดำเนินงานทั้งในสตาร์ทอัพและองค์กรระดับโลก ก่อนที่จะดำรงตำแหน่งปัจจุบัน เขาเคยดำรงตำแหน่ง CTO ที่ Trigo โดยนำการพัฒนา AI และระบบการมองเห็นคอมพิวเตอร์สำหรับร้านค้าปลอดความเสี่ยงและป้องกันการขาดทุนในระดับใหญ่ ในขณะที่จัดตำแหน่งผลิตภัณฑ์และ R&D ให้สอดคล้องกับการใช้งานเชิงพาณิชย์จริง ในช่วงก่อนหน้านี้ เขาเคยดำรงตำแหน่งผู้นำ R&D ที่ Trigo และใช้เวลาเกินกว่า 10 ปีในหน่วย 8200 ของอิสราเอล โดยสุดท้ายเขาได้รับการยอมรับในระดับชาติสำหรับการทำงานของเขา
Check Point Software Technologies (CHKP ) เป็นผู้นำระดับโลกด้านความปลอดภัยไซเบอร์ โดยให้บริการโซลูชันความปลอดภัยที่ขับเคลื่อนด้วย AI และส่งมอบผ่านคลาวด์ เพื่อป้องกันองค์กรและรัฐบาลจากภัยคุกคามดิจิทัลที่ซับซ้อนมากขึ้น บริษัทให้บริการมากกว่า 100,000 องค์กรทั่วโลกด้วยแพลตฟอร์มที่ครอบคลุม ซึ่งป้องกันเครือข่าย สภาพแวดล้อมคลาวด์ จุดสิ้นสุด และผู้ใช้ โดยใช้แนวทางที่ให้ความสำคัญกับการป้องกันการโจมตีก่อนที่จะเกิดขึ้น โครงสร้างของบริษัทใช้ AI และข้อมูลอันตรายแบบเรียลไทม์ เพื่อทำให้การดำเนินงานด้านความปลอดภัยง่ายขึ้น ลดความเสี่ยง และช่วยให้องค์กรสามารถขยายตัวได้อย่างปลอดภัยเมื่อใช้ AI การประมวลผลคลาวด์ และระบบกระจาย
คุณได้นำโครงการความปลอดภัยไซเบอร์และ AI ระดับใหญ่ สร้างระบบ AI ที่ Trigo และตอนนี้ดูแลกลยุทธ์ AI ที่ Check Point คุณได้สังเกตเห็นโหมดการล้มเหลวใดบ้างเมื่อระบบ AI ถูกย้ายจากสภาพแวดล้อมที่ควบคุมไปยังการผลิต โดยเฉพาะเมื่อพวกมันได้รับอนุญาตให้ใช้เครื่องมือและข้อมูลองค์กร?
สองสิ่งที่เปลี่ยนแปลงไปอย่างมีนัยสำคัญในการผลิต คือ ขนาดและความเสี่ยง ในห้องทดลอง อัตราผลบวกลวง 0.1% อาจดูยอดเยี่ยม แต่เมื่อคุณกำลังประมวลผลล้านๆ การโต้ตอบ สิ่งนี้จะแปลเป็นเหตุการณ์หลายพันครั้งที่ต้องการการดูแล สถิติผิดปกติในการทดสอบกลายเป็นความเป็นจริงในการดำเนินงานในระดับใหญ่
สิ่งที่สอง คือ การต้องเผชิญกับภัยคุกคาม ในสภาพแวดล้อมที่ควบคุม ข้อมูลเข้าเป็นมิตรและคาดการณ์ได้ ในโลกแห่งความเป็นจริง ผู้ใช้บางคนและผู้กระทำความผิดจะพยายามหลอกลวงระบบ โดยใช้ทุกช่องทางข้อมูลที่ไม่น่าเชื่อถือเพื่อควบคุมพฤติกรรม การเปลี่ยนแปลงจากการสาธิตไปสู่การผลิตไม่ใช่ปัญหาในการปรับขนาด แต่เป็นการเปลี่ยนแปลงจากสภาพแวดล้อมที่ร่วมมือกันไปสู่สภาพแวดล้อมที่ถูกโต้แย้ง ซึ่งต้องการสมมติฐานการออกแบบที่แตกต่างออกไปอย่าง根本
ในระบบอัตลักษณ์ ซึ่งโมเดลสามารถเรียก API, ประมวลผลโค้ด และเชื่อมต่อการกระทำ อะไรคือพื้นผิวการโจมตีที่สำคัญที่สุดที่ทีมความปลอดภัยยังไม่ได้เตรียมการอย่างเหมาะสม?
พื้นผิวที่สำคัญที่สุดที่ทีมส่วนใหญ่ประเมินต่ำคือข้อมูลเอง ระบบอัตลักษณ์เข้าถึงแหล่งข้อมูลที่ไม่น่าเชื่อถือ — อีเมลที่เข้ามา เว็บไซต์ ตั๋ว Jira โค้ดโอเพ่นซอร์ส เอกสารภายนอก ข้อมูลนี้ถูกดูดและวิเคราะห์โดยโมเดลในระหว่างกระบวนการให้เหตุผล
สิ่งนี้สร้างความเสี่ยงสองประการ ประการแรก คือ การปนเปื้อนหน่วยความจำ — โดยที่เนื้อหาที่ถูกจัดการสามารถเปลี่ยนแปลงการตอบสนองและตัดสินใจของโมเดลในอนาคตโดยไม่มีการ.inject ตรงๆ ประการที่สอง คือ การ.inject ตรงๆ โดยอ้อม — โดยที่คำสั่งอันตรายถูกฝังในข้อมูลภายนอกและปลดปล่อยโมเดลจากภายใน โดยไม่ต้องสัมผัสกับคำสั่งโดยตรง ผู้โจมตีเพียงแค่ปลูกคำสั่งไว้ที่ตัวแทนจะพบ
การ.inject ตรงๆ มักถูกมองว่าเป็นปัญหาโมเดล แต่ในทางปฏิบัติกลายเป็นปัญหาที่เกิดจากระบบ ควรออกแบบโครงสร้างใหม่เพื่อแยกการรับเข้าโมเดล การใช้เครื่องมือ และการเข้าถึงข้อมูลที่สำคัญอย่างไร?
การ.inject ตรงๆ ไม่ใช่ปัญหาระดับโลกที่มีวิธีแก้ปัญหาแบบเดียวกัน การที่อินพุตใดๆ ถูกต้องหรือเป็นอันตรายขึ้นอยู่กับบริบททั้งหมด การขอให้ตัวแทน “เปลี่ยนรหัสผ่านผู้ดูแลระบบ” เป็นสิ่งที่ถูกต้องหากเป็นตัวแทนฝ่ายสนับสนุนเทคนิค การขอเดียวกันนี้กับแชทบอทของร้านค้าออนไลน์ถือเป็นการโจมตี
ดังนั้น โครงสร้างจึงมีความสำคัญมากกว่าเทคนิคการตรวจจับใดๆ ระบบต้องการกลไกที่ไม่แน่นอนและไม่แน่นอนทำงานร่วมกัน กลไกการควบคุมที่แน่นอนจัดการการเข้าถึงเครื่องมือและข้อมูลตามอัตลักษณ์ของตัวแทน อัตลักษณ์ของผู้ใช้ และบทบาทที่กำหนดไว้ของระบบ กลไกการควบคุมที่ไม่แน่นอนแบบโมเดลเพิ่มความสามารถในการเข้าใจภาษา บริบท และความตั้งใจ คุณต้องการทั้งสองชั้น — การบังคับใช้นโยบายที่เข้มงวดและเหตุผลเชิงปัญญา — เพราะไม่เช่นนั้นจะไม่เพียงพอ
หลายตัวแทน AI พึ่งพาการสร้างข้อมูลและแหล่งข้อมูลภายนอก อะไรคือความเสี่ยงรอบๆ การปนเปื้อนข้อมูลและการจัดการบริบทในกระบวนการเหล่านี้ และสามารถบรรเทาได้อย่างไรในขณะทำงาน?
ความเสี่ยงแตกต่างกันไปตามทิศทางการไหลของข้อมูล สำหรับแหล่งข้อมูลภายใน ความเสี่ยงหลักคือการรั่วไหลของข้อมูลที่สำคัญ — การเปิดเผยข้อมูลส่วนบุคคล การแบ่งปันข้อมูลระหว่างลูกค้า และข้อมูลภายในที่ถูกเปิดเผยต่อผู้ที่ไม่ได้รับอนุญาต สำหรับแหล่งข้อมูลภายนอก ความเสี่ยงรวมถึงการเอนเอียงของโมเดลจากข้อมูลที่ไม่ได้รับการยืนยัน การ.inject ตรงๆ โดยอ้อมที่ฝังไว้ในเนื้อหาที่ดึงมา และการพึ่งพาแหล่งข้อมูลที่ไม่น่าเชื่อถือหรือถูกจัดการ
การบรรเทาต้องเกิดขึ้นที่ระดับการทำธุรกรรม ในแบบเรียลไทม์ ทุกการโต้ตอบของตัวแทนจะต้องได้รับการรักษาความปลอดภัยในทั้งสองทิศทาง — เพื่อให้แน่ใจว่าข้อมูลที่สำคัญไม่รั่วไหลจากภายในออกไป และเพื่อให้แน่ใจว่าข้อมูลที่เป็นอันตรายหรือหลอกลวงไม่ถูกส่งจากภายนอกเข้าสู่ระบบหรือโมเดล คุณไม่สามารถแก้ปัญหานี้ได้ที่เวลาดึงข้อมูลเท่านั้น เพราะบริบทเป็นแบบไดนามิก และภูมิทัศน์ของภัยคุกคามเปลี่ยนแปลงอย่างต่อเนื่อง
คุณแนะนำ AI Defense Plane ซึ่งเป็นชั้นควบคุมที่รวมกันสำหรับการใช้ AI ของพนักงาน การใช้แอปพลิเคชัน และระบบอัตลักษณ์ อะไรคือความท้าทายด้านโครงสร้างที่ยิ่งใหญ่ที่สุดในการสร้างระบบที่สามารถสังเกตและบังคับใช้นโยบายทั่วทั้ง AI ที่กระจัดกระจาย?
เรามองว่าในอนาคต ระบบอัตลักษณ์จะครอบคลุมจุดสิ้นสุด แอปพลิเคชัน บริการ SaaS และเวิร์กโหลดคลาวด์ — ทั้งหมดนี้เชื่อมต่อกันใน “อินเทอร์เน็ตของตัวแทน” ความคิดเบื้องหลัง AI Defense Plane คือการค้นพบ จัดการ และปกป้องโครงสร้างพื้นฐานอัตลักษณ์ขององค์กรที่กำลังพัฒนาในหน้าต่างเดียว
ความท้าทายด้านโครงสร้างที่สำคัญที่สุดคือการประเมินโปรไฟล์ความเสี่ยงและบริบทของตัวแทนแต่ละตัวในขณะเดียวกันกับที่พัฒนาการป้องกันแบบเรียลไทม์สำหรับการทำธุรกรรมอัตลักษณ์ทุกครั้ง ซึ่งหมายถึงการรักษาอัตราการปิดกั้นที่สูงต่อภัยคุกคามที่แท้จริง ในขณะที่ลดผลบวกลวงให้เหลือน้อยที่สุด — ทั้งหมดนี้ต้องทำที่ความเร็วและขนาดการผลิต และทั่วทั้งสภาพแวดล้อมที่กำลังทำงานหลายแห่ง การสร้างระบบที่สามารถสังเกตและบังคับใช้นโยบายทั่วทั้ง AI ที่กระจัดกระจายและพัฒนาอย่างรวดเร็วนี้ ต้องทำให้เราต้องคิดใหม่เกี่ยวกับวิธีการสรุปและประเมินกิจกรรม AI ในระดับพื้นฐาน
แพลตฟอร์มนี้เน้นการตัดสินใจแบบเรียลไทม์ที่ความเร็วของเครื่องจักรทั่วภาษาและกระบวนการทำงาน คุณสร้างสมดุลระหว่างข้อจำกัดด้านความล่าช้าและความจำเป็นในการตรวจสอบและควบคุมการกระทำที่ขับเคลื่อนด้วย AI ในสภาพแวดล้อมการผลิตอย่างไร?
เราพัฒนาและฝึกอบรมโมเดลพื้นฐานสำหรับการป้องกันภัยคุกคามโดยเฉพาะ จากนั้นใช้เทคนิคการกลั่นกรองเพื่อให้พวกมันทำงานได้อย่างมีประสิทธิภาพสูง ซึ่งช่วยให้เราสามารถรันการอนุมานได้อย่างรวดเร็วและใช้คำนวณน้อย — แม้แต่บน CPU หรือ GPU ทั่วไป — ในขณะที่ยังคงครอบคลุมหลายภาษาและหลายรูปแบบ รวมถึงการวิเคราะห์ภาพและเสียงด้วยความแม่นยำสูงสุด
แนวทางนี้ช่วยให้เราสามารถตรวจสอบการทำธุรกรรมอัตลักษณ์อย่างลึกซึ้งโดยไม่กลายเป็นปัญหาการขัดขวาง การรักษาความปลอดภัยที่แนะนำความล่าช้าจะถูกข้าม การรักษาความปลอดภัยที่มองไม่เห็นในกระบวนการทำงานแต่บังคับใช้การควบคุมที่มีความหมายคือสิ่งที่ถูกติดตั้งและยังคงอยู่
ตัวแทน AI มีการทำงานโดยมอบหมายสิทธิ์ในการเข้าถึงข้ามระบบหลายระบบ องค์กรควรคิดใหม่เกี่ยวกับการจัดการอัตลักษณ์และการเข้าถึงสำหรับตัวแทน非มนุษย์ โดยเฉพาะอย่างยิ่งเมื่อตัวแทนขยายขอบเขตการทำงานผ่านการใช้เครื่องมืออย่างไร?
ข้อผิดพลาดที่องค์กรส่วนใหญ่ทำคือการรักษาตัวแทน AI ไว้ว่าเป็นส่วนขยายของผู้ใช้หรือบัญชีบริการแบบดั้งเดิม ไม่เช่นนั้น ควรพิจารณาว่าตัวแทนเหล่านี้เป็น “พนักงานดิจิทัล” — สิ่งที่มีบทบาท ความรับผิดชอบ และขอบเขตที่กำหนดไว้
อัตลักษณ์ของตัวแทนควรถูกกำหนดโดยสามมิติ — กระบวนการทำงานที่เฉพาะเจาะจง ผู้ใช้ที่เป็นเจ้าของหรือสร้างตัวแทน และผู้ใช้ที่โต้ตอบกับตัวแทนในขณะนั้น ทั้งสามปัจจัยเหล่านี้กำหนดสิ่งที่ตัวแทนควรได้รับอนุญาตให้ทำ องค์กรต้องใช้หลักการ Zero-Trust กับตัวแทน — ไม่ควรให้ความไว้วางใจโดยอิงจากจุดกำเนิด แต่ควรตรวจสอบพฤติกรรมอย่างต่อเนื่องและบังคับใช้การเข้าถึงแบบมีสิทธิ์น้อยที่สุดในทุกขั้นตอน หากไม่เช่นนั้น ตัวแทนจะสะสมอำนาจมากกว่าที่ใครๆ ตั้งใจไว้โดยไม่ทราบ
องค์กรส่วนใหญ่มีการใช้ AI ในรูปแบบเงา คู่ขับ และสคริปต์ภายในแล้ว ควรเก็บข้อมูลที่ไหนเพื่อให้ได้ภาพที่ชัดเจนเกี่ยวกับว่า AI ติดต่อกับข้อมูลที่สำคัญอย่างไร?
การมองเห็นต้องทำงานที่ระดับการทำธุรกรรมของตัวแทน — ไม่ใช่แค่คำสั่งและคำตอบ แต่การเรียกใช้เครื่องมือ ข้อมูลที่เครื่องมือส่งกลับ และการกระทำที่เกิดขึ้นตามมา ทีมความปลอดภัยต้องเห็นช่องทางการดำเนินการทั้งหมด — สิ่งที่ถูกถาม ข้อมูลที่เข้าถึงได้ เครื่องมือที่ถูกเรียกใช้ พารามิเตอร์ที่ถูกส่ง และสิ่งที่เกิดขึ้นต่อไป
หากไม่มีการมองเห็นด้วยระดับการทำธุรกรรม คุณไม่สามารถตอบคำถามพื้นฐานเกี่ยวกับการเปิดเผย การใช้ในทางที่ผิด หรือผลกระทบได้ AI ที่ซ่อนอยู่ไม่ใช่สิ่งที่อันตรายเพราะมันอยู่ แต่เป็นอันตรายเพราะมันทำงานโดยไม่มีการกำกับดูแลหรือการมองเห็น
การทดสอบระบบอัตลักษณ์ด้วยการโจมตีแบบแดงเป็นเรื่องที่แตกต่างจากการทดสอบแอปพลิเคชันแบบคงที่ คุณจำลองพฤติกรรมที่เป็นอันตรายในกระบวนการทำงานหลายขั้นตอนและพบกับวิธีการโจมตีแบบไหนบ้าง?
เราดำเนิน Gandalf (https://gandalf.lakera.ai) ซึ่งเป็นการออกกำลังกายการโจมตี AI แบบแดงขนาดใหญ่ที่สุดในโลก เป็นแพลตฟอร์มที่ผู้ใช้จริงพยายาม说服ตัวแทน AI ให้ละเมิดขอบเขตการป้องกัน สิ่งนี้ทำให้เรามีฐานข้อมูลที่ไม่ซ้ำกันและเติบโตอย่างต่อเนื่องของเทคนิคการโจมตีที่แท้จริง — ไม่ใช่การโจมตีทางทฤษฎี แต่วิธีการที่คนจริงๆ ใช้เพื่อหลอกลวงระบบ AI
เรานำฐานข้อมูลนี้มาขับเคลื่อนความสามารถในการทดสอบแบบแดงของเรา การโจมตีที่เราเห็นบ่อยที่สุดเกี่ยวข้องกับผู้ใช้ที่ชักชวนให้ตัวแทนละเมิดขอบเขตการป้องกัน — โดยการ.inject ตรงๆ โดยอ้อม การเปลี่ยนคำอธิบายอย่างสร้างสรรค์ การจัดการบริบท และการขยายความไว้วางใจอย่างต่อเนื่องในระหว่างการโต้ตอบหลายขั้นตอน ปัญหาเหล่านี้มองไม่เห็นหากคุณทดสอบเพียงคำสั่งเดียว คุณต้องทดสอบลำดับและแคมเปญที่โจมตีแบบยั่งยืน
เมื่อผู้โจมตีเริ่มใช้ตัวแทนอัตโนมัติในการสืบสวนสิ่งแวดล้อมอย่างต่อเนื่อง คุณคาดหวังว่าการป้องกันจะเปลี่ยนไปสู่การควบคุมแบบปรับเปลี่ยนได้แบบเรียลไทม์ที่ขับเคลื่อนด้วย AI และโครงสร้างนั้นดูเหมือนอย่างไรในทางปฏิบัติ?
ใช่ การป้องกันที่คงที่ไม่สามารถตามทันผู้โจมตีที่ใช้การโจมตีแบบอัตโนมัติอย่างต่อเนื่อง การป้องกันต้องกลายเป็นแบบปรับเปลี่ยนได้ แบบเรียลไทม์ และอัตโนมัติ ซึ่งหมายถึงการตรวจสอบพฤติกรรม AI อย่างต่อเนื่อง การประเมินความเสี่ยงอย่างต่อเนื่อง และการบังคับใช้เมื่อนโยบายถูกละเมิด ความเร็วและขนาดของการโจมตีที่ขับเคลื่อนด้วย AI จะต้องถูกตอบโต้ด้วยการป้องกันที่มีความเร็วและขนาดเท่ากัน
ในทางปฏิบัติ การรักษาความปลอดภัยกลายเป็นวงจรป้อนกลับมากกว่าชุดกฎ การตรวจสอบระบบ AI และประเมินผลอย่างต่อเนื่อง การจำกัดขอบเขตการทำงานอย่างไดนามิก ในความเร็วและขนาดที่ระบบ AI ทำงาน สิ่งนี้เป็นขั้นตอนที่จำเป็นหากองค์กรต้องการใช้ AI อย่างปลอดภัยในระดับองค์กร
ขอขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Check Point Software Technologies.












