SOC ของคุณจับตาดูพนักงาน แต่ไม่เคยจับตาดู Vendor ของคุณเลย

การละเมิดข้อมูลที่เกี่ยวข้องกับบุคคลที่สาม (third-party) เพิ่มขึ้นจาก 15% เป็น 30% ภายในปีเดียว ซึ่งเป็นการเปลี่ยนแปลงที่ใหญ่ที่สุดในรอบปีเดียวเท่าที่รายงาน Verizon 2025 Data Breach Investigations Report เคยบันทึกไว้ การถูกโจมตีผ่านห่วงโซ่อุปทาน (supply chain) มีค่าใช้จ่ายเฉลี่ยอยู่ที่ 4.91 ล้านดอลลาร์ และใช้เวลาถึง 267 วันในการตรวจพบและควบคุม ซึ่งเป็นวงจรที่ยาวนานที่สุดในบรรดาช่องทางการโจมตีทั้งหมดที่ IBM ติดตาม ในฟิลิปปินส์ องค์กรที่ถูกละเมิดข้อมูลผ่านบุคคลที่สามในปีที่ผ่านมาทั้งหมด 100% ถูกเจาะผ่านบัญชี Vendor ไม่ใช่การโจมตีตรงที่ perimeter ขององค์กรเอง

ภาคการผลิตเป็นอุตสาหกรรมที่ถูกโจมตีมากที่สุดในโลกตอนนี้ และคิดเป็น 40% ของการโจมตีทางไซเบอร์ทั้งหมดในเอเชียแปซิฟิก โรงงานส่วนใหญ่ที่เราทำงานด้วยในประเทศไทยมี SIEM มี SOC และมีการตรวจจับที่ครอบคลุมพนักงานและ endpoint ของตัวเองในระดับที่สมเหตุสมผล แต่แทบไม่มีโรงงานไหนเลยที่มี rule แจ้งเตือนเมื่อบัญชี VPN ของ vendor เครื่องจักรล็อกอินตอนตีสองจากประเทศที่ไม่เคยเชื่อมต่อมาก่อน

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

บริการที่เกี่ยวข้อง

ทำไมนี่ถึงเป็นจุดบอด ไม่ใช่ความประมาท

Baseline ของ SOC ทั่วไปถูกสร้างขึ้นจากพฤติกรรมพนักงาน: ผู้ใช้รายนี้ปกติล็อกอินจากกรุงเทพฯ ระหว่าง 8 โมงเช้าถึง 1 ทุ่ม เข้าถึงระบบสามระบบนี้ และไม่เคยแตะต้องเซิร์ฟเวอร์การเงิน การเบี่ยงเบนจาก baseline นี้จะสร้าง alert

บัญชี Vendor และผู้รับเหมาไม่เข้ากับโมเดลนี้ ด้วยเหตุผลเชิงโครงสร้างสามข้อ:

พวกเขาถูกออกแบบให้ไม่สม่ำเสมอโดยเจตนา วิศวกรฝ่ายซัพพอร์ตของ vendor อาจล็อกอินปีละครั้งเพื่ออัปเดตเฟิร์มแวร์ ในเวลาที่เหมาะกับ timezone ของเขา จากเครือข่ายอะไรก็ได้ที่เขาใช้อยู่ในขณะนั้น ไม่มี baseline ที่มั่นคงให้เบี่ยงเบนออกไป ซึ่งหมายความว่าการตรวจจับพฤติกรรมส่วนใหญ่จะเพิกเฉยต่อบัญชีเหล่านี้ หรือไม่ก็สร้าง noise มากจนนักวิเคราะห์เรียนรู้ที่จะเพิกเฉยต่อ alert เหล่านั้น

พวกเขามองไม่เห็นในชั้น identity องค์กรส่วนใหญ่สร้างบัญชี vendor แบบเดียวกับที่สร้างบัญชีพนักงาน — AD group เดียวกัน รูปแบบการตั้งชื่อเดียวกัน บางครั้งใช้ login เดียวกันร่วมกันในหมู่พนักงานของ vendor หลายคน ไม่มีอะไรในระบบ identity ที่บอกความแตกต่างระหว่าง "นี่คือบุคคลที่สามที่มีการเข้าถึงแบบจำกัดเวลาและขอบเขต" กับ "นี่คือวิศวกรของเราเอง"

ไม่มีใครรับผิดชอบการ deprovision งานวิจัยของ Bitsight ปี 2026 พบว่ามีเพียง 1 ใน 3 ขององค์กรเท่านั้นที่ตรวจสอบความสัมพันธ์กับบุคคลที่สามอย่างต่อเนื่อง ส่วนใหญ่พึ่งพารอบการประเมินเป็นระยะซึ่งทิ้งช่องว่างการมองเห็นหลายเดือน สัญญากับ vendor สิ้นสุดลง ใบแจ้งหนี้หยุด แต่ credential VPN ที่ออกให้เมื่อสิบแปดเดือนก่อนยังคงทำงานอย่างเงียบๆ เพราะไม่มีทีมใดรับผิดชอบการปิดมัน

ภายใต้ PDPA องค์กรมีหน้าที่ต้องแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลภายใน 72 ชั่วโมงหลังทราบเหตุการละเมิดข้อมูล — บัญชี vendor ที่ไม่มีใครติดตามคือสาเหตุคลาสสิกที่ทำให้องค์กร "ทราบ" ช้าเกินไปที่จะทำตามกำหนดเวลานั้น และสำหรับผู้ประกอบการโครงสร้างพื้นฐานสำคัญภายใต้ พระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 มาตรา 59 ซึ่งกำหนดให้ต้องมีมาตรการเฝ้าระวังและตอบสนองต่อภัยคุกคาม การเข้าถึงของ vendor ที่ไม่ถูกตรวจสอบถือเป็นช่องว่างการปฏิบัติตามกฎหมายโดยตรง ไม่ใช่แค่ความเสี่ยงทางเทคนิค

นี่คือปัญหา identity debt แบบเดียวกับที่เราเคยเขียนไว้ก่อนหน้านี้ — ทุกบัญชีที่ไม่มีเจ้าของศูนย์กลางจะกลายเป็นบัญชีที่ไม่มีใครจำได้ว่าต้องลบ — เพียงแต่บัญชี vendor มีความเสี่ยงเพิ่มเติม: องค์กรมีการควบคุมน้อยกว่ามากว่า credential นั้นถูกเก็บและใช้งานอย่างไรที่ฝั่ง vendor

สองพื้นที่การโจมตี รากปัญหาเดียวกัน

Vendor ฝั่ง IT: เส้นทาง MSP และ SaaS integration

ผู้ให้บริการจัดการ (MSP) แพลตฟอร์มบิลลิ่ง และ SaaS integration มักถือ credential หรือ API key แบบถาวรที่มีสิทธิ์เข้าถึงระบบหลักในวงกว้าง เมื่อผู้ให้บริการรายใดรายหนึ่งถูกเจาะ ผู้โจมตีจะได้รับสิทธิ์เข้าถึงที่ถูกต้องตามกฎหมายและได้รับความไว้วางใจอยู่แล้วทันที — ไม่ต้องฟิชชิ่ง ไม่ต้องใช้ exploit และไม่มี alert ใดที่ดูเหมือนการบุกรุกเพราะในทางเทคนิคแล้วมันยังไม่ใช่

Vendor ฝั่ง OT: เส้นทางการบำรุงรักษาเครื่องจักร

เราเคยพูดถึงรูปแบบนี้อย่างละเอียดในบทความเรื่องความปลอดภัยของ floor โรงงาน แต่ควรย้ำอีกครั้งที่นี่: ความเสี่ยงส่วนใหญ่ของการเข้าถึงระยะไกลในภาคอุตสาหกรรมมาจาก VPN concentrator ที่ตั้งอยู่บน OT segment โดยตรง ด้วย credential ที่ vendor เครื่องจักรตั้งไว้เมื่อหลายปีก่อนและไม่มีใครหมุนเวียนตั้งแต่นั้นมา เส้นทางนี้ข้าม IT/OT boundary ไปโดยสิ้นเชิง เพราะมันถูกสร้างขึ้นเป็นช่องทางบำรุงรักษาที่ถูกต้องตามกฎหมาย ไม่ใช่เส้นทางโจมตี — จนกว่ามันจะถูกใช้เป็นเส้นทางโจมตี

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

flowchart TD
  A["บัญชี Vendor หรือผู้รับเหมา"] --> B["ถูกสร้างเหมือนบัญชีพนักงาน"]
  A --> C["ไม่มีขอบเขตเวลาที่จำกัด"]
  A --> D["ไม่มีระดับความเสี่ยงเฉพาะ"]
  B --> E["กลืนเข้ากับ log การยืนยันตัวตนปกติ"]
  C --> F["การเข้าถึงยังคงอยู่หลังสัญญาสิ้นสุด"]
  D --> G["ไม่มี correlation rule ที่ปฏิบัติต่างออกไป"]
  E --> H["SOC เห็นการล็อกอินที่ถูกต้อง ไม่ใช่เหตุการณ์เสี่ยง"]
  F --> H
  G --> H
  H --> I["พบการละเมิดข้อมูลหลังผ่านไป 267 วัน หากพบเลย"]

สิ่งที่จะปิดช่องว่างนี้ได้จริง

การตรวจสอบการเข้าถึงของ vendor ไม่ใช่การขยายขนาดของการตรวจสอบพนักงาน แต่ต้องปฏิบัติต่อ identity ของบุคคลที่สามเป็นหมวดหมู่ของตัวเองตั้งแต่ต้นจนจบ

1. ติด tag identity ของ vendor ตั้งแต่ตอน provision ไม่ใช่หลังเกิดเหตุการณ์ ทุกบัญชี vendor ผู้รับเหมา และ integration ต้องมี attribute ที่แยกแยะได้ชัดเจน — OU เฉพาะใน directory รูปแบบการตั้งชื่อ หรือ SSO group เฉพาะสำหรับบุคคลที่สาม หากไม่มีสิ่งนี้ ไม่มี rule การตรวจจับใดที่จะปฏิบัติต่อการเข้าถึงของ vendor แตกต่างออกไปได้ เพราะไม่มีอะไรบอก SIEM ว่าบัญชีไหนคือ vendor ตั้งแต่แรก

2. สร้าง correlation rule ตาม vendor risk tier ไม่ใช่ baseline ความผิดปกติทั่วไป แทนที่จะพยายามเรียนรู้รูปแบบ "ปกติ" ของบัญชีที่ล็อกอินปีละสองครั้ง ให้เขียน rule ที่ชัดเจน: การเข้าถึงของบัญชี vendor นอกช่วงเวลาบำรุงรักษาที่อนุมัติล่วงหน้าคือระดับความรุนแรงสูงโดยค่าเริ่มต้น การเข้าถึงระบบนอกขอบเขตที่บันทึกไว้คือระดับความรุนแรงสูงโดยค่าเริ่มต้น

3. จำกัดเวลาการเข้าถึงตั้งแต่ต้นทาง วิธีแก้ที่มีประสิทธิภาพที่สุดคือเชิงสถาปัตยกรรม ไม่ใช่เชิงตรวจจับ: credential VPN และ remote-support ของ vendor ควรหมดอายุอัตโนมัติเว้นแต่จะขยายเวลาอย่างชัดเจนสำหรับช่วงบำรุงรักษาที่กำลังดำเนินอยู่

4. ส่ง alert ที่ติด tag vendor ผ่าน playbook แยกต่างหาก เมื่อบัญชีถูกติด tag แล้ว ชั้น SOAR สามารถใช้เส้นทาง escalation ที่แตกต่างออกไป — ความผิดปกติของบัญชี vendor ควรแจ้งเตือนคนโดยอัตโนมัติแทนที่จะปิดอัตโนมัติ เพราะปริมาณต่ำแต่ผลกระทบที่อาจเกิดขึ้นสูง นี่คือหลักการtriage-assist ก่อน auto-close แบบเดียวกับที่ใช้กับ alert fatigue โดยทั่วไป

5. ทำให้การ deprovision เป็นการทบทวนตามกำหนดการ ไม่ใช่ความหวัง ผูกทุกบัญชี vendor เข้ากับวันสิ้นสุดสัญญาตั้งแต่ตอนสร้าง และตั้งการทบทวนอัตโนมัติทุก 90 วันสำหรับ credential vendor ใดๆ ที่ไม่มีสัญญาที่ยังใช้งานอยู่ตรงกัน

flowchart TD
  A["Vendor onboarding"] --> B["ติด tag identity: vendor OU + ขอบเขต + วันหมดอายุ"]
  B --> C["กำหนดช่วงเวลาการเข้าถึง"]
  C --> D["Correlation rule: การเข้าถึงนอกช่วงเวลา = ความรุนแรงสูง"]
  D --> E["SOAR: alert ของ vendor ส่งถึงนักวิเคราะห์ ไม่ auto-close"]
  E --> F["สัญญาสิ้นสุด"]
  F --> G["ทบทวน deprovisioning ตามกำหนดการ"]
  G --> H["เพิกถอน credential ที่ต้นทาง"]

simpliSOC จัดการการเข้าถึงของ Vendor อย่างไร

simpliSOC ทำงานบน Wazuh สำหรับการตรวจจับ DFIR-IRIS สำหรับการจัดการเคส และ Shuffle สำหรับระบบอัตโนมัติ — stack เดียวกับที่อยู่เบื้องหลังการติดตั้ง SOC อื่นๆ ของเรา การขยายให้ครอบคลุมการเข้าถึงของ vendor ไม่ต้องใช้เครื่องมือใหม่ เพียงแค่ชุด rule ที่แตกต่างออกไป:

บัญชี vendor และผู้รับเหมาถูกติด tag ที่ชั้น identity (AD OU หรือ SSO group) เพื่อให้ correlation rule ของ Wazuh ใช้ baseline ความรุนแรงที่แตกต่างจาก baseline พนักงานทั่วไป
Rule ของช่วงเวลาการเข้าถึงถูกเขียนอย่างชัดเจนต่อสัญญา vendor แต่ละราย — เหตุการณ์การยืนยันตัวตนใดๆ นอกช่วงเวลาบำรุงรักษาที่ตกลงกันไว้จะถูกตั้งค่าเป็นความรุนแรงสูงไม่ว่า IP reputation จะเป็นอย่างไร
Playbook ของ Shuffle ส่ง alert ที่ติด tag vendor ตรงไปยังนักวิเคราะห์พร้อมบริบทของสัญญาและขอบเขตที่แนบมาล่วงหน้า แทนที่จะรวมเข้ากับคิว auto-triage ทั่วไป
เคสใน IRIS ที่เกี่ยวข้องกับบัญชี vendor ถูกติด tag แยกต่างหาก เพื่อให้การทบทวนรายไตรมาสสามารถดึงเหตุการณ์ที่เกี่ยวกับ vendor ทั้งหมดได้โดยไม่ต้องขุดค้นในบันทึกเคสทั่วไป

สิ่งเหล่านี้ไม่ได้แทนที่การประเมินความเสี่ยง vendor ที่ทีมจัดซื้อหรือ GRC ของคุณควรทำอยู่แล้วก่อนเซ็นสัญญา แต่มันปิดช่องว่างระหว่างการประเมินนั้นกับสิ่งที่ SOC ของคุณเห็นจริงเมื่อ vendor มีการเข้าถึงแบบ live — ซึ่งตามข้อมูลของ Verizon คือจุดที่เกือบหนึ่งในสามของการละเมิดข้อมูลเกิดขึ้นในปัจจุบัน

อยากได้ความเห็นที่สองว่า SOC ของคุณมองเห็นการเข้าถึงของ Vendor ได้มากแค่ไหนในตอนนี้?
คุยกับทีม simpliSOC → hello@simplico.net

คำถามที่พบบ่อย

ความเสี่ยงจาก vendor เป็นปัญหาของฝ่ายจัดซื้อไม่ใช่ SOC ไม่ใช่หรือ?
ทั้งสองอย่าง การประเมินความเสี่ยง vendor ก่อนเซ็นสัญญา (ความมั่นคงทางการเงิน ท่าทีด้านความปลอดภัย ใบรับรอง) เป็นหน้าที่ของฝ่ายจัดซื้อและ GRC สิ่งที่เกิดขึ้นหลังเซ็นสัญญาแล้ว — ว่าการเข้าถึงจริงของ vendor ถูกตรวจสอบ กำหนดขอบเขต และเพิกถอนตามกำหนดการหรือไม่ — เป็นหน้าที่ของ SOC

เราใช้ SaaS หลายตัวที่มี API integration แม้ไม่มี vendor เข้ามาที่ไซต์งาน หลักการนี้ใช้กับเราไหม?
ใช้ได้ และอาจสำคัญยิ่งกว่าด้วยซ้ำ API key ที่มีขอบเขตกว้างมีความเสี่ยงในทางปฏิบัติเหมือนกับบัญชี VPN ของ vendor — การเข้าถึงที่ถาวรและได้รับอนุญาตซึ่งไม่เข้ากับ baseline พฤติกรรมผู้ใช้ปกติ

เราจะรู้ได้อย่างไรว่าตอนนี้เรามีการเข้าถึงของ vendor มากแค่ไหน?
เริ่มจากการตรวจสอบ ไม่ใช่การซื้อเครื่องมือ: ดึงทุกบัญชี AD/SSO ที่ไม่ได้ผูกกับพนักงานปัจจุบัน ทุก API key ที่ใช้งานอยู่ และทุก credential VPN แล้วจับคู่แต่ละอันกับสัญญาที่ยังใช้งานอยู่ ช่องว่างที่ปรากฏขึ้น — บัญชีที่ไม่มีสัญญาตรงกัน — มักเป็นสิ่งแรกที่ควรปิด

เรื่องนี้ใช้กับการเข้าถึงของ vendor ฝั่ง OT ต่างจากฝั่ง IT หรือไม่?
หลักการเหมือนกันทุกประการ — ติด tag กำหนดขอบเขต จำกัดเวลา แจ้งเตือนเมื่อเบี่ยงเบน — แต่การเข้าถึงของ vendor ฝั่ง OT มีความเสี่ยงสูงกว่า เพราะ credential vendor เครื่องจักรที่ถูกเจาะสามารถเข้าถึงระบบการผลิตได้โดยตรง ดูเพิ่มเติมที่บทความเรื่องความปลอดภัย floor โรงงาน

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

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