Third-Party & Supply Chain Risk

องค์กรขนาดกลางและใหญ่ในประเทศไทยพึ่งพา vendor ภายนอกจำนวนมาก ครอบคลุม SaaS, cloud, MSP, MSSP และผู้รับจ้างพัฒนาระบบ ขณะที่การประเมินความเสี่ยงของ vendor ส่วนใหญ่ยังทำเพียงตอน onboarding บทนำนี้อธิบายว่าเหตุใด third-party risk จึงต้องถูกมองเป็น continuous process ไม่ใช่ one-time checklist และชี้ให้เห็นเหตุการณ์ supply chain ที่ผ่านมาอย่าง SolarWinds, Kaseya, MOVEit และ XZ Utils ที่เปลี่ยนวิธีคิดของหน่วยกำกับทั่วโลกเกี่ยวกับ vendor risk

 

องค์กรขนาดกลางและขนาดใหญ่ในประเทศไทยมักพึ่งพา vendor ภายนอกจำนวนมาก ครอบคลุมทั้ง SaaS, ผู้ให้บริการ cloud, MSP, MSSP และผู้รับจ้างพัฒนาระบบ ขณะที่ฝ่ายจัดซื้อและฝ่ายกฎหมายมักประเมินความเสี่ยงเพียงตอน onboarding การประเมินแบบครั้งเดียวไม่เพียงพอต่อสถานการณ์ที่ vendor เผชิญภัยคุกคามตลอดเวลา Series M จึงเน้นแนวทาง continuous monitoring แทนการประเมินเพียงรอบการต่อสัญญา

 

Series M จัดโครงสร้างตามวงจรของความสัมพันธ์กับ vendor ตั้งแต่การ tier vendor ตามความเสี่ยง การทำ due diligence ในขั้นตอน onboarding การจัดการ software supply chain ผ่าน SBOM การประเมินความเสี่ยงเฉพาะของ MSP/MSSP และ cloud provider ที่เข้าถึงระบบ privileged การ continuous monitoring ตลอดอายุสัญญา และการ offboarding อย่างปลอดภัยเมื่อสิ้นสุดสัญญา

 

2,700+

องค์กรที่ได้รับผลกระทบจากเหตุการณ์ MOVEit ผ่าน vendor เพียงรายเดียว

 

15%

ของเหตุการณ์ข้อมูลรั่วที่เริ่มต้นจาก third party เพิ่มจาก 9% ในเวลาสองปี (Verizon DBIR)

 

300+

ราย Vendor ภายนอกโดยเฉลี่ยที่องค์กรขนาดกลางในประเทศไทยพึ่งพา

 

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

 

 

CHAPTER ONE · TIERING

 

 

กรอบ tiering ที่ใช้ได้จริงแบ่ง vendor เป็น 3–4 ระดับตามผลกระทบหาก vendor หยุดให้บริการ หรือหาก vendor ถูก compromise — Tier 1 คือ vendor ที่ถ้าหยุดทันทีจะทำให้ business หยุด, Tier 2 คือ vendor ที่มีข้อมูลส่วนบุคคลหรือเข้าถึง production, Tier 3 คือ vendor ที่ไม่มี access กับข้อมูลสำคัญ

 

“vendor ที่เข้าถึงข้อมูลส่วนบุคคลและ vendor ที่ออกใบแจ้งหนี้ไม่ควรถูกประเมินด้วย checklist เดียวกัน”

 

 

CHAPTER TWO · DUE DILIGENCE

 

 

questionnaire ที่ดีของ CAIQ หรือ SIG Lite มี 200–300 ข้อ แต่การตอบ 'yes' ทุกข้อไม่ใช่หลักฐานของ security — สิ่งที่สำคัญคือ evidence ที่แนบมาด้วย เช่น policy, audit report, penetration test summary, SOC 2 Type II report ที่อายุไม่เกิน 12 เดือน

 

สำหรับ vendor Tier 1 การสัมภาษณ์ CISO หรือ Head of Security ของ vendor เป็น signal ที่เทียบเท่าการตอบ questionnaire — ถ้า vendor ไม่มี dedicated security leader ที่พูดเรื่อง security operations ได้ เป็นสัญญาณที่ต้องพิจารณา

 

“questionnaire 300 ข้อที่ vendor ตอบใน 1 วัน ไม่ใช่ assurance — เป็นแค่เอกสารที่รอการตรวจสอบ”

 

 

CHAPTER THREE · SBOM

 

 

Executive Order 14028 ของสหรัฐฯ และแนวปฏิบัติของ NIST ผลักดัน SBOM เป็นมาตรฐานใหม่ — SBOM คือรายการ component ทั้งหมดใน software ตั้งแต่ direct dependency, transitive dependency, library version และ license เมื่อช่องโหว่ใหม่เกิด องค์กรจะทราบทันทีว่า software ใดได้รับผลกระทบ

 

รูปแบบมาตรฐานของ SBOM มี 2 กลุ่มหลัก — SPDX และ CycloneDX — ทั้งสองรองรับโดย tool อย่าง Syft, Trivy, Snyk, GitHub Dependabot SBOM ต้อง regenerate ทุก build และเก็บใน registry ที่ query ได้

 

“SBOM ไม่ใช่เอกสาร — เป็นฐานข้อมูลที่ถามกลับได้เมื่อมีช่องโหว่ใหม่ในวันถัดไป”

 

 

CHAPTER FOUR · MSP/MSSP RISK

 

 

MSP ที่ติดตั้ง RMM (Remote Monitoring and Management) agent บน endpoint ทั่วองค์กรคือ vendor ที่มีสิทธิ์เทียบเท่า admin ภายใน — incident ที่ผ่านมาอย่าง Kaseya VSA และ ConnectWise ScreenConnect ทำให้ระบบ MSP ถูกใช้เป็นช่องทางกระจาย ransomware ไปยังลูกค้าหลายราย

 

การควบคุม MSP ต้องรวม MFA บังคับในการ access, role-based access ที่จำกัด privilege, session recording, และการแบ่ง tenancy ที่ลูกค้าแต่ละรายไม่สามารถเห็นกันได้ องค์กรที่ใช้ MSP ควรขอรายงาน SOC 2 Type II และประเมิน TPRM ของ MSP เอง

 

“MSP ที่มี RMM agent บน endpoint ทั่วองค์กร คือหนึ่งใน vendor ที่ต้องประเมินเข้มข้นที่สุด”

 

 

CHAPTER FIVE · CONTINUOUS MONITORING

 

 

การประเมิน vendor ปีละครั้งไม่สามารถจับความเปลี่ยนแปลงของ security posture ได้ทัน — vendor ที่เพิ่งถูก breach เมื่อเดือนก่อน ยังคงอยู่ในสถานะ 'ผ่านการประเมิน' ตลอดปี เครื่องมือ TPRM สมัยใหม่อย่าง SecurityScorecard, BitSight, UpGuard ทำ external attack surface monitoring ของ vendor ให้อัตโนมัติ

 

“SOC 2 report เก่ากว่า 12 เดือนไม่ใช่หลักฐานของ posture ปัจจุบัน”

 

 

CHAPTER SIX · OFFBOARDING

 

 

การปิดสัญญา vendor อย่างเรียบร้อยครอบคลุม 3 ด้าน — การปิดสิทธิ์ทางเทคนิค (user account, API key, VPN, certificate), การเรียกคืนหรือทำลายข้อมูล (ตามเงื่อนไขสัญญาและ PDPA), และการเรียกคืนทรัพย์สิน (อุปกรณ์, token, badge) checklist ที่ครอบคลุม 35 รายการช่วยให้ไม่มีสิ่งใดตกหล่น

 

การขอ certificate of data destruction จาก vendor พร้อม evidence (log ของการ delete, attestation letter) เป็นหลักฐานสำคัญที่ audit และ DPO ต้องการ — หากไม่มี หลักฐาน การแจ้ง PDPC เมื่อมี incident ย้อนหลังจะยากมาก

 

“การ offboard vendor ที่ไม่เรียบร้อย ทำให้องค์กรยังมีข้อมูลรั่วได้อีกหลายเดือนหลังสัญญาจบ”

 

 

Third-party risk เป็นความเสี่ยงที่ขยายไปนอกขอบเขตของการควบคุมโดยตรงขององค์กร — การวางระบบ TPRM ที่ดีคือการเตรียมพร้อมสำหรับเหตุการณ์ที่เราไม่สามารถป้องกันได้ 100% แต่ยังควบคุมผลกระทบได้

 

หากท่านต้องการเนื้อหาฉบับเต็มที่ครอบคลุมทุกบท พร้อมแนวปฏิบัติเชิงเทคนิค ตัวอย่าง workflow และคำศัพท์เฉพาะทาง กดตาม URL นี้เพื่อดาวน์โหลด: