การจัดการความเสี่ยงบุคคลที่สาม (TPRM) สำหรับ APAC

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

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

ความเสี่ยงที่คุณยอมรับโดยไม่รู้ตัว #

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

ภาพนี้เล่นออกมาเป็นรูปแบบเดิมซ้ำ ๆ:

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

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

TPRM ที่ถูกต้องมีลักษณะเป็นอย่างไร #

TPRM ไม่ใช่การกรอกแบบสอบถามปีละครั้งแล้วลืม มันคือวงจรที่ต่อเนื่อง:

1. จัดทำ inventory และจัดลำดับความเสี่ยง: รู้ว่าคุณพึ่งใคร และ vendor ไหนเข้าถึงอะไร vendor ที่สัมผัสข้อมูลลูกค้า (เช่น ผู้ประมวลผลการชำระเงิน) อยู่คนละชั้นกับ supplier ปากกา
2. การตรวจสอบความมั่นคงปลอดภัยของบุคคลที่สามตามสัดส่วน: vendor ที่สำคัญต้องได้ การตรวจสอบความมั่นคงปลอดภัยจริง เช่น หลักฐานใบรับรอง เช่น SOC 2 หรือ ISO 27001 หรือการประเมินจากบุคคลที่สาม
3. ข้อผูกมัดตามสัญญา: ระบุ SLA การแจ้งเหตุ ข้อกำหนดด้านความมั่นคงปลอดภัย และสิทธิตรวจสอบลงในสัญญาเสียก่อนจะเซ็น ไม่ใช่หลังเกิดเหตุ
4. การเฝ้าระวังอย่างต่อเนื่อง: ภัยของ vendor เปลี่ยนตามเวลา ตรวจสอบซ้ำเมื่อสัญญาต่ออายุ เมื่อขอบเขตเปลี่ยน หรือเมื่อมีสัญญาณว่าท่าทีของ vendor เปลี่ยนไป

กรอบอย่าง ISO/IEC 27001 (ควบคุม supplier) NIST CSF และ PCI DSS Requirement 12.8 ต่างบังคับให้มีการจัดการบุคคลที่สามอย่างต่อเนื่องเป็นรายการควบคุม ไม่ใช่ทางเลือก

ทำไมแบบสอบถามถึงใช้แค่เป็นตัวคัดกรอง #

แบบสอบถามความมั่นคงปลอดภัยของ vendor เป็นจุดเริ่มต้นที่มีประโยชน์ แต่เป็นหลักฐานที่อ่อน มันคือ vendor บรรยายตัวเอง มันจะไม่ระบุเองว่า “เราไม่เคย encrypt ที่ rest” และมักถูกเขียน โดยทีมขายมากกว่าทีมวิศวกรรม

เมื่อ vendor มีความสำคัญมากพอ (สัมผัสข้อมูลละเอียดอ่อน ประมวลผลการชำระเงิน ถือระบบที่สำคัญ) คุณต้องก้าวข้ามการยืนยันจากเจ้าตัวไปสู่หลักฐานอิสระ: รายงาน SOC 2 Type II ใบรับรอง ISO 27001 ที่ถูกต้อง และสิทธิ์ตรวจสอบตามสัญญาที่คุณ ใช้จริง ไม่ใช่แค่เก็บไว้ในลิ้นชัก

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

สัญญาคือมาตรการควบคุม ไม่ใช่แค่เอกสารกฎหมาย #

หลายองค์กรปฏิบัติต่อสัญญา vendor เป็นเรื่องของทีมกฎหมายล้วน ๆ แล้วพบว่าสัญญามีผล ต่อความมั่นคงปลอดภัยน้อยมากเมื่อเกิดเหตุ สัญญาที่เขียนไว้ดีคือมาตรการควบคุมที่สำคัญ:

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

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

ความเป็นจริงเชิงกฎระเบียบในประเทศไทย #

หน่วยงานกำกับดูแลกำลังเข้มงวดเรื่องความรับผิดชอบต่อบุคคลที่สามมากขึ้น แนวปฏิบัติ IT Risk ของธนาคารแห่งประเทศไทย กำหนดให้สถาบันการเงิน ต้องบริหารความเสี่ยงจาก third-party รวมถึงผู้ให้บริการเทคโนโลยีภายนอก PDPA ของไทยกำหนดภาระผูกพันต่อผู้ประมวลผลข้อมูลส่วนบุคคล และ PCI DSS กำหนดให้รักษา inventory ของผู้ให้บริการทั้งหมดที่มีผลกระทบต่อความมั่นคงปลอดภัยของข้อมูลผู้ถือบัตร

ข้อความคือความรับผิดชอบไม่ได้ออกจากองค์กรของคุณเมื่อข้อมูลออกจากอาคารของคุณ การจัดการบุคคลที่สามอย่างเข้มงวดคือสิ่งที่แปลงข้อความนั้นเป็นการปฏิบัติ

เริ่มจากตรงไหน #

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

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