2220 คำ
11 นาที
CyberSecurity Foundation EP.02 — 4 เคสที่เปลี่ยนวงการ (Equifax / Target / Capital One / SolarWinds)
สารบัญ

Series: CyberSecurity Foundation — รากฐาน Security สำหรับยุค AI (ภาษาคน)

Part 0 — WHY: เมืองนี้ทำไมต้องมียาม

  1. EP.01 — Cybersecurity คือเรื่องของคุณ
  2. EP.02 — 4 เคสที่เปลี่ยนวงการ ← คุณอยู่ตรงนี้
  3. EP.03 — CIA Triad — 3 คำถามที่ทุก control ต้องตอบ (เร็วๆ นี้)
  4. EP.04 — Defense in Depth + Diversity of Controls (เร็วๆ นี้)
  5. EP.05 — Assume Breach + Risk (เร็วๆ นี้)

Part 1-6 (HOW / Identity / Data / Infrastructure / Operations / Governance) — กำลังเขียนต่อ

EP ที่แล้วเราคุยกันว่า เมืองของเรามีของมีค่ามากขึ้นทุกวัน — บัญชี LINE ที่ส่งข้อความหาแม่ ฐานข้อมูลลูกค้าใน Excel เก่าๆ admin Facebook page ที่ลูกค้าตามอยู่ห้าหมื่นคน. โจรเก่งขึ้นทุกวันเพราะ AI ทำให้ scale ได้แบบที่ไม่เคยมีมาก่อน. และยามที่ดีที่สุดไม่ใช่กำแพงสูงที่สุด แต่คือชาวเมืองที่เข้าใจเกม. ตอนปิด EP ผมทิ้งประโยคไว้ว่า “หลายคนยังคิดว่ามันเป็นเรื่องบริษัทใหญ่ ไม่ใช่บริษัทเรา” — EP นี้เลยอยากพาไปดูว่าจริงๆ “บริษัทใหญ่” ที่ว่าโดนเพราะอะไร

ในประวัติศาสตร์ cybersecurity ครับ มี 4 เคสที่ทุก expert ทั่วโลกใช้สอน — Equifax, Target, Capital One, SolarWinds. ไม่ใช่เพราะเป็นเคสที่ใหญ่ที่สุด (มีเคสที่ใหญ่กว่านี้อีกหลายเคส) แต่เพราะแต่ละเคสสอน lesson คนละด้านที่ครอบคลุมเกือบทุก pattern ของการพัง. อ่านจบ EP นี้ คุณจะมีกรอบ 4 อันที่เอาไปจับบริษัทตัวเอง + คู่ค้า + vendor ได้ทันทีว่า “เราเสี่ยงตรงไหน”

ผมอยากให้นึกภาพ 4 เมืองใหญ่ที่ถูกปล้น 4 รูปแบบ ครับ. เมืองแรกผ่าน audit เทศบาลผ่านฉลุย — แต่โดนปล้นทางท่อระบายน้ำที่ผู้ตรวจไม่ได้ดู. เมืองที่สองโดนปล้นเพราะช่างซ่อมแอร์ที่มีคีย์การ์ดถูกล้วงกระเป๋า. เมืองที่สามเพิ่งเช่าตึกใหม่ในเมือง — เจ้าของตึกล็อกประตูตึกให้แล้ว แต่ลืมล็อกประตูห้องตัวเอง. เมืองที่สี่หนักที่สุด — ผู้สร้างบ้านของเมืองวางท่อยาพิษไว้ในบ้านใหม่ทุกหลัง ผ่าน inspection ปกติ ดูเหมือนปลอดภัย แต่คนในนั้นโดนยาช้าๆ

เริ่มที่เมืองแรกครับ

Equifax 2017 — เมืองที่ผ่าน audit แต่ยังโดนปล้น#

Equifax ครับ — ถ้าคุณไม่รู้จักชื่อนี้ลองนึกถึงเครดิตบูโรครับ. ในอเมริกามี 3 บริษัทใหญ่ที่เก็บประวัติเครดิตของคนทั้งประเทศ Equifax คือ 1 ใน 3 นั้น. แปลว่าในเซิร์ฟเวอร์ของเขามีเลข Social Security Number (SSN — เลขบัตรประชาชนของอเมริกัน) เลขบัตรเครดิต ประวัติเงินกู้ ของคนอเมริกันแทบทั้งประเทศ. ของในเซฟของเมืองนี้คือเอกสารยืนยันตัวตนของคนทั้งชาติ — ของชิ้นเดียวที่ขโมยไปแล้วซื้อบ้าน เปิดบัญชี กู้เงินในนามคนอื่นได้

Equifax เพิ่งผ่านการ audit ใหญ่หลายตัวก่อนเกิดเหตุครับ. PCI DSS (Payment Card Industry Data Security Standard — มาตรฐานความปลอดภัยของอุตสาหกรรมบัตรเครดิตที่ Visa/Mastercard บังคับ) ผ่าน. มาตรฐานอื่นๆ ผ่าน. ผู้ตรวจสอบมาดูระบบ ดูเอกสาร ดู policy แล้วเซ็นรับรองว่าโอเค — เหมือนเทศบาลมาตรวจป้อมแล้วบอกว่า “กำแพงสูง ปืนใหญ่พร้อม ยามครบ ผ่าน”

แล้วเรื่องเกิดยังไงครับ. มีนาคม 2017 มีคนค้นพบช่องโหว่ใน Apache Struts (ซอฟต์แวร์โอเพนซอร์สที่ใช้ทำเว็บแอป — Equifax ใช้เว็บนี้รับเรื่อง dispute เครดิตของลูกค้า). ช่องโหว่นี้ชื่อ CVE-2017-5638 — CVE = Common Vulnerabilities and Exposures — เลขทะเบียนช่องโหว่กลางของวงการ. ทีม Apache ออก patch ปิดช่องนี้ออกมาในวันเดียวกัน. ฝ่าย IT ของ Equifax ก็รู้ — ได้รับ email แจ้งเตือนภายในตามขั้นตอน

แต่ — และนี่คือคำว่า “แต่” ที่ทำเรื่องราว 147 ล้าน records — Equifax ใช้ scanner (เครื่องมือสแกนช่องโหว่อัตโนมัติ) เป็นตัวค้นหาว่าเซิร์ฟเวอร์ตัวไหนของบริษัทที่ต้องลง patch. scanner ตัวที่ Equifax ใช้รุ่นเก่า + ตั้งค่าผิด ทำให้มันมองไม่เห็นเซิร์ฟเวอร์ตัวที่ดูแลระบบ dispute. ทีม IT เลยเข้าใจว่า “ไม่มีเซิร์ฟเวอร์ตัวไหนต้อง patch” — ก็ปล่อยไว้

2 เดือนผ่านไป โจรหาเซิร์ฟเวอร์ตัวนี้เจอ. ส่ง request พิเศษเข้าไปทาง CVE-2017-5638. ระบบรับ shell command ของโจร — แปลว่าโจรเข้ามาอยู่ในเครื่อง Equifax แล้ว. จากตรงนั้นโจรเดินเล่นในระบบ 76 วันต่อเนื่อง — เกือบ 11 สัปดาห์. ขโมยฐานข้อมูลออกมาช้าๆ ปริมาณน้อยๆ ทีละเล็กทีละน้อย ผ่าน connection ที่ดูเหมือน traffic ปกติ. รวมแล้วเอาไปได้ 147 ล้าน records — SSN + วันเกิด + ที่อยู่ + เลขใบขับขี่ของคนอเมริกันเกือบครึ่งประเทศ

ที่หนักกว่าคือ Equifax รู้ตัวเมื่อปลายเดือนกรกฎาคม. รอบในบริษัทช่วงระหว่างที่รู้แล้วยังไม่ประกาศนั้น มีผู้บริหารบางคนขายหุ้น Equifax ออกหลายล้านดอลลาร์ก่อนข่าวออก — ภายหลังโดนสอบเรื่อง insider trading. CEO ลาออก. CIO ลาออก. CSO ลาออก. รวมค่าปรับ + ค่าฟ้องร้อง + เงินชดเชยลูกค้า ทะลุ 700 ล้านดอลลาร์. และความเชื่อมั่นในชื่อ “Equifax” — เสียหายชนิดที่ฟื้นไม่ได้

ลองคิดเปรียบเทียบกับป้อมปราการดูครับ. ผู้ตรวจสอบของเทศบาลเดินรอบป้อม ดูกำแพง — โอเค ดูปืนใหญ่ — โอเค ดูเอกสารยาม — โอเค ออกใบรับรอง “ป้อมนี้ผ่านมาตรฐาน”. ปัญหาคือผู้ตรวจสอบมาดูในวันที่ X. คืนวันที่ X+45 ฝนตกหนัก ท่อระบายน้ำที่ไม่ได้อยู่ในรายการตรวจดันแตก — โจรปีนเข้าทางนั้น. กระดาษรับรองจากเทศบาลที่ติดผนังป้อมไม่ได้ช่วยอะไรเลย เพราะมันคือ snapshot — ภาพถ่ายของระบบในวันใดวันหนึ่ง — ส่วนความปลอดภัยจริงๆ เป็น continuous — เกิดขึ้นต่อเนื่องทุกวินาที

นี่คือ lesson ที่วงการเรียกว่า Compliance ≠ Security ครับ — ผ่าน checklist ของผู้ตรวจ ไม่ได้แปลว่าโจรปล้นไม่ได้. หรือถ้าจะเปรียบกับชีวิตประจำวันให้เห็นชัด — ผ่านแบบประเมินสุขภาพประจำปี ≠ ไม่ได้เป็นมะเร็ง. แบบประเมินดูสิ่งที่อยู่ใน checklist เท่านั้น. มะเร็งบางชนิดเริ่มหลัง check-up รอบที่แล้วและจะเจอตอน check-up รอบหน้า — ระหว่างนั้นคุณเดินรอบเมืองอย่างมั่นใจว่าสุขภาพดี เพราะมีใบรับรอง

มุมผู้บริหาร: ถ้าวันนี้ผู้บริหารถามทีม IT ว่า “เราปลอดภัยไหม” แล้วได้คำตอบว่า “ปลอดภัยครับ เราเพิ่งผ่าน audit” — นั่นคือสัญญาณเตือน ไม่ใช่คำตอบที่ปลอดภัย. คำถามที่ดีกว่าคือ “patch ล่าสุดที่เรายังไม่ลงคือตัวไหน เพราะอะไร?” “scanner เราหาเซิร์ฟเวอร์เจอครบไหม รู้ได้ยังไง?” “เคยมี server ตัวไหนที่ทีมลืม inventory ไหม?” สามคำถามนี้เปิดบาดแผลได้เร็วกว่ารายงาน audit หนาเป็นนิ้ว

Target 2013 — โจรเข้าทางช่างซ่อมแอร์#

เคสที่สองครับ — Target — ห้างใหญ่ของอเมริกาที่ทุกบ้านในชานเมืองไปซื้อของวันเสาร์. ปลายปี 2013 ช่วงเทศกาล Thanksgiving — ช่วงที่คนอเมริกันออกไปจับจ่ายใช้สอยเตรียมคริสต์มาส — Target โดนปล้นข้อมูลบัตรเครดิตลูกค้า 40 ล้านใบ + ข้อมูลส่วนตัว (ชื่อ ที่อยู่ เบอร์ อีเมล) อีก 70 ล้าน. รวมแล้วใกล้ 1 ใน 3 ของผู้ใหญ่ทั้งประเทศอเมริกาโดน

ที่น่าสนใจคือ Target ลงทุนเรื่อง security ดีมากในสายตาคนวงในตอนนั้นครับ. มี SOC (Security Operations Center — ห้องควบคุมความปลอดภัยที่มีคนนั่งดูจอ 24 ชั่วโมง) มี firewall ระดับ enterprise มีระบบเตือนภัยตัวใหม่ที่เพิ่งติดตั้งราคาหลายล้านดอลลาร์ (FireEye). แล้วโจรเข้ามาทางไหน?

โจรไม่ได้เข้ามาทางประตูหน้าของ Target ครับ — โจรเข้ามาทาง Fazio Mechanical — บริษัทรับติดตั้ง + ดูแลระบบทำความเย็นและเครื่องปรับอากาศ (HVAC = Heating, Ventilation, Air Conditioning) ที่ Target จ้างให้ดูแลห้างหลายร้อยสาขา. Fazio เป็นบริษัทกลาง ๆ มีพนักงานไม่กี่สิบคน ไม่ได้มีระบบ security เทียบเท่า Target

ลำดับเหตุการณ์เป็นแบบนี้ครับ. มีนาคม 2013 Fazio Mechanical ได้รับอีเมล phishing — อีเมลปลอมที่หลอกให้ดาวน์โหลดไฟล์อะไรสักอย่าง. พนักงานคนหนึ่งของ Fazio กดเปิดไฟล์ — มัลแวร์ชื่อ Citadel (ตัวที่ขโมย password จาก browser) เข้าไปอยู่ในเครื่อง. มัลแวร์นั้นค่อยๆ ขโมย credential ที่ Fazio เก็บไว้ในเครื่อง — รวมถึง password ที่ Fazio ใช้ login เข้าระบบ vendor portal ของ Target (Target มี portal ให้คู่ค้าใช้ส่งใบเรียกเก็บเงิน ดู work order ฯลฯ)

โจรได้ password นั้นมาก็ login เข้า portal ของ Target เลยครับ — ในมุมระบบ Target นี่คือ “Fazio login เข้ามาทำงานปกติ”. จากตรงนั้น โจรหาทางขยาย access จาก vendor portal → ข้ามไปยังเครือข่ายของพนักงาน Target → ข้ามไปยังเครือข่าย POS (Point of Sale — เครื่องคิดเงินจุดชำระ). ที่ POS นี่แหละครับโจรติดตั้ง BlackPOS malware (มัลแวร์ที่ดักจับข้อมูลบัตรเครดิตตอนรูดผ่านเครื่อง — เพราะตอนนั้นบัตรในอเมริกายังเป็นแบบแถบแม่เหล็ก ข้อมูลอ่านออกมาเป็นตัวเลขดิบในเครื่องชั่วขณะหนึ่ง)

โจรอยู่ในระบบ POS ของ Target ราว 2 สัปดาห์ครับ — ตรงช่วง Black Friday พอดี — ดักข้อมูลบัตรลูกค้าที่จ่ายเงินวันละหลายล้านใบ ส่งออกไปเก็บใน server กลางใน Target เอง แล้วทยอยส่งออกนอกบริษัทผ่าน Russia. ที่น่าเศร้าคือระบบ FireEye ที่ Target เพิ่งซื้อมา มันเห็นและส่ง alert จริง — แต่ทีม security ที่นั่งดูจอ ignore เพราะคิดว่าเป็น false alarm

สรุปความเสียหาย CEO + CIO ของ Target ลาออก. ค่าใช้จ่ายรวมทุกอย่าง — ค่าเปลี่ยนบัตรให้ลูกค้า ค่าฟ้องร้องจากธนาคาร ค่าปรับ ค่าทนาย ค่า PR — ทะลุ 300 ล้านดอลลาร์ ใกล้ๆ 400 ล้าน. ลูกค้าฟ้องร้องเป็น class action หลายปี. และคำว่า “Target breach” กลายเป็นกรณีศึกษามาตรฐานในทุกคอร์ส cybersecurity ทั่วโลก

lesson ของเคสนี้คือ Supply chain = ด่านหน้า ครับ — ความปลอดภัยของคุณ = ความปลอดภัยของ vendor ที่อ่อนแอที่สุดที่คุณเชื่อมต่อด้วย. Target ลงทุน security 100 ล้าน — ไม่ช่วย เพราะโจรไม่ได้พยายามฝ่า Target. โจรฝ่า Fazio ก่อน — บริษัทเล็กที่ไม่มี budget security เลย — แล้วใช้ Fazio เป็นกุญแจเข้า Target. โจรในยุคนี้ไม่งี่เง่าครับ เขาไม่ปีนกำแพงสูง — เขาเดินตามคนที่มีกุญแจ

ลองนึกภาพง่ายๆ — ตึกออฟฟิศของคุณมียามหน้าตึกเข้มงวด ต้องมีบัตรพนักงานหรือบัตรวีไอพีถึงเข้าได้. แต่ทุกเย็น 5 โมง pizza delivery มาส่งของ ยามรู้จักหน้า — แตะคีย์การ์ดของ pizza guy → ผ่านล็อบบี้ขึ้นลิฟต์ไปชั้นไหนก็ได้. วันหนึ่ง pizza guy คนนั้นทำคีย์การ์ดหายในรถเมล์. คนที่เก็บได้มาที่ตึกคุณ — ยามเห็นคีย์การ์ดถูกต้อง ปล่อยผ่าน. ตึกของคุณตอนนั้น = ปลอดภัยเท่ากับสติของ pizza guy ที่คุณไม่เคยรู้จักชื่อ

เรื่องนี้เกี่ยวกับธุรกิจไทยยังไง? เกี่ยวมากเลยครับ. คนทำบัญชีฟรีแลนซ์ที่คุณส่งไฟล์ลูกค้า + bank statement ให้ทุกเดือน — นั่นคือ vendor. เอเจนซีโฆษณาที่คุณให้ admin access ของ Facebook page — นั่นคือ vendor. บริษัทเช่าโกดังที่ใช้ระบบ access card ร่วมกับออฟฟิศคุณ — นั่นคือ vendor. โปรแกรมเมอร์ outsource ที่คุณให้ access ฐานข้อมูล production — นั่นคือ vendor. ทุกคนคือประตูเข้าบริษัทคุณ. และความสามารถ security ของพวกเขามักจะน้อยกว่าคุณ

มุมผู้บริหาร: ลองนั่งเขียนรายการครับ — “ใครบ้างที่ตอนนี้เข้าถึงข้อมูลหรือระบบของบริษัทผมได้”. เขียนทั้งหมดทุกคน — พนักงานเก่าที่ออกไปแล้วแต่ลืม revoke / ฟรีแลนซ์ / agency / vendor / ที่ปรึกษา / IT support บริษัทภายนอก / บัญชี / ทนาย. ทีนี้ถามต่อทุกคน: “เขาใช้ password ที่ไหนอีกบ้าง?” “เขามี 2FA ไหม?” “เขาเก็บไฟล์ของเราในเครื่องตัวเอง หรือ in cloud ของใคร?” ผมการันตีว่า list นี้ของบริษัทไทย 90% มีอย่างน้อย 3 คนที่ “ลืม revoke ตอนเลิกจ้าง” — และโจรรู้ดีว่านี่คือประตูที่เปิดทิ้งไว้

Capital One 2019 — เมืองที่เช่าตึกใหม่แล้วลืมล็อกห้อง#

เคสที่สาม Capital One — ธนาคารใหญ่ของอเมริกา ราว top-10 ของประเทศ. ปี 2019 ข้อมูลลูกค้า 100 ล้านราย + ใบสมัครบัตรเครดิตอีก 140,000 SSN + 80,000 เลขบัญชี ถูกขโมย. ที่ทำให้เคสนี้น่าสนใจไม่ใช่ตัวเลข แต่คือ “วิธีที่โจรเข้ามา” — เพราะมันเปิดบทใหม่ของวงการที่เรียกว่า “cloud security

เริ่มจากบริบทก่อน. ปี 2015-2019 บริษัทใหญ่ทั่วโลกเริ่มย้ายระบบจาก data center ตัวเอง → ขึ้น cloud (AWS, Azure, GCP). Capital One เป็น 1 ใน flagship case ของ AWS — ธนาคารใหญ่กล้าย้ายระบบ banking ขึ้น cloud — เขียน case study ขายของกัน. แปลว่าข้อมูลลูกค้า Capital One ไปอยู่ใน AWS S3 buckets (พื้นที่เก็บไฟล์บน AWS — เหมือน Google Drive แต่สำหรับองค์กร) จำนวนมาก

โจรชื่อ Paige Thompson — เธอเป็นอดีตวิศวกร AWS ที่ลาออกมาแล้ว แปลว่ารู้ระบบของ AWS ดีระดับลึก. เธอรู้เรื่องหนึ่งที่คนทั่วไปไม่รู้ — AWS มี metadata service (บริการเล็กๆ ที่อยู่ภายในเซิร์ฟเวอร์ AWS ทุกตัว ใช้บอกว่าเซิร์ฟเวอร์ตัวนี้ชื่ออะไร มี role อะไร เข้าถึงอะไรได้บ้าง — เป็น API ภายในที่เซิร์ฟเวอร์ใช้คุยกับ AWS เอง). metadata service เวอร์ชันเก่า (IMDSv1) มีจุดอ่อน — ถ้ามีคนนอกหลอกให้เซิร์ฟเวอร์ส่ง request ไปยัง metadata service ได้ ก็จะได้ credential ของเซิร์ฟเวอร์ตัวนั้นออกมา

นี่คือเทคนิคที่ชื่อ SSRF (Server-Side Request Forgery — การหลอกให้เซิร์ฟเวอร์ส่งคำขอออกไปยังที่อยู่ที่โจรกำหนด). ตามปกติคุณส่งคำขอเข้าไปที่เซิร์ฟเวอร์เพื่อขอข้อมูลกลับมา. SSRF คือพลิกกลับ — โจรหาช่องในแอปที่ให้ “เซิร์ฟเวอร์ของเป้า” เป็นคนยิงคำขอออกไป ตามที่โจรสั่ง — รวมถึงยิงคำขอไปยังที่อยู่ภายในของระบบเองอย่าง metadata service

Thompson ค้นพบว่า WAF (Web Application Firewall — กำแพงไฟล์ระดับเว็บแอป) ของ Capital One ตั้งค่าผิด ทำให้เธอใช้ SSRF ผ่าน WAF ได้. ขั้นตอนคร่าวๆ คือ:

  1. ส่งคำขอที่ออกแบบมาเฉพาะเข้า WAF ของ Capital One — WAF หลงเอาคำขอนี้ส่งไปคุยกับ metadata service ของตัวมันเอง
  2. metadata service ตอบกลับด้วย credential ของ role ที่ WAF ใช้
  3. ใช้ credential นั้น login เข้า S3 buckets ของ Capital One — เพราะ role ของ WAF ดันมีสิทธิ์อ่าน buckets เยอะเกินไป (least privilege violation)
  4. ดาวน์โหลดข้อมูล 100 ล้าน records ออกมา

จุดที่หลายคนงงคือ — ทำไม Thompson โดนจับ? คำตอบคือเธอโพสต์อวดบน GitHub + Slack ของกลุ่ม hacker. คนคนหนึ่งเห็นโพสต์ แจ้ง Capital One ผ่าน responsible disclosure → Capital One ตรวจสอบเจอ → แจ้ง FBI → จับ. Thompson ติดคุก. ฝั่ง Capital One โดน OCC ปรับ 80ล้านดอลลาร์(2020)บวกกับยอมsettleคดีclassactionของลูกค้าอีก80 ล้านดอลลาร์ (2020) บวกกับยอม settle คดี class action ของลูกค้าอีก 190 ล้านดอลลาร์ (2022) — และ CISO ในตอนนั้นถูกย้ายตำแหน่งหลังเหตุการณ์

lesson ของเคสนี้คือ Shared Responsibility Model ครับ — โมเดล “ใครรับผิดชอบส่วนไหน” ของ cloud ที่บริษัทไทยส่วนใหญ่ไม่เข้าใจ. AWS / Azure / Google Cloud ไม่ใช่ “ที่ที่ปลอดภัยอัตโนมัติ” ครับ. cloud provider ดูแลความปลอดภัยของ infrastructure (datacenter ทางกายภาพ, hypervisor, network layer ลึก, hardware) — แต่ลูกค้า (คุณ) ดูแลความปลอดภัยของ everything that you put on it — config ของแอปคุณ, สิทธิ์ของ role, การตั้งค่า bucket, password, code ที่มี vulnerability

ลองนึกภาพให้ง่ายครับ — เช่าตึกใหม่ในเมือง. เจ้าของตึก (cloud provider) ดูแล: โครงสร้างตึกไม่พัง ลิฟต์ทำงาน ไฟติด ระบบประปา security guard ที่ล็อบบี้ตึก. คุณ (tenant) ดูแล: ล็อกประตูห้องตัวเอง ไม่เปิดประตูให้คนแปลกหน้า อย่าทิ้งกุญแจในล็อบบี้. ถ้าคุณเช่าห้องในตึกที่ดีที่สุดของเมือง แล้วปล่อยประตูห้องเปิดทั้งคืน — คุณโดนปล้น เจ้าของตึกไม่ผิด. Capital One คือ tenant ที่ “ลืมล็อกประตูห้องตัวเอง” — แม้ AWS จะล็อกประตูตึกให้ดีแค่ไหน

อีก lesson คือ Insider knowledge เป็นอาวุธ — Thompson ไม่ใช่ random hacker. เธอเคยทำงาน AWS รู้ว่าจุดอ่อนของระบบอยู่ตรงไหน. ในธุรกิจคุณก็เหมือนกัน — โปรแกรมเมอร์ที่เพิ่งลาออก, IT support ที่เคยรู้ระบบ, freelancer ที่เคยมี access. ไม่ได้แปลว่าเขาทุกคนจะกลายเป็นโจร — แต่ความรู้เรื่องระบบของเขาคือ asset ของฝ่ายโจมตี. เคยมี case ที่บริษัทไทยถูกคู่แข่งจ้างอดีตพนักงาน IT มาเปิด backdoor ให้ — เรื่องจริง

มุมผู้บริหาร: ถ้าบริษัทคุณใช้ cloud อยู่ (อย่างน้อยใช้ Google Workspace, Microsoft 365, AWS, GCP — นี่ก็ cloud หมด) ลองถามคำถามนี้ — “ใครคือคนสุดท้ายที่เช็คว่า bucket / folder ไหนใน cloud ของเราเป็น public บ้าง?” + “พนักงานคนล่าสุดที่ลาออก — เรา revoke access ใน cloud ครบไหม?” + “role ของ admin คนไหนใน cloud ของเรามีสิทธิ์ ‘อ่าน database production’?”. 3 คำถามนี้บริษัทไทย 80% ตอบไม่ได้ทันที — แปลว่าตอนนี้คุณอาจจะมี bucket public ที่ลืมไว้แล้ว 2 ปี

SolarWinds 2020 — ผู้สร้างบ้านวางท่อยาพิษในทุกบ้าน#

เคสที่สี่ — และเคสที่ทำให้ทุกคนในวงการ “หนาวสะท้าน” — SolarWinds 2020 ครับ

ก่อนเล่าต้องอธิบายว่า SolarWinds คือใคร. SolarWinds เป็นบริษัทซอฟต์แวร์อเมริกา ผลิตเครื่องมือชื่อ Orion — software ที่ใช้ monitor ระบบ network ขององค์กร (ดูว่า server ตัวไหนช้า ตัวไหนล่ม สวิตช์ไหนหลุด). Orion ไม่ใช่ของฮิตในตลาดผู้บริโภค แต่ในตลาด enterprise มันคือ standard — ลูกค้าของ SolarWinds ตอนนั้นมีกว่า 300,000 องค์กร ครอบคลุม Fortune 500 ส่วนใหญ่ + กระทรวงรัฐบาลอเมริกาหลายกระทรวง + บริษัทยักษ์ใหญ่ของวงการ tech รวมถึง Microsoft + FireEye + Cisco

ลูกค้าของ Orion ติดตั้งซอฟต์แวร์นี้ในเครือข่ายลึกที่สุดขององค์กร — เพราะ Orion ต้อง “เห็น” ทุกอย่างถึงจะ monitor ได้. แปลว่า Orion มีสิทธิ์เข้าถึงสูงมากในทุกองค์กรที่ติดตั้ง

ตอนนี้มาที่ตัวร้าย. APT29 (Advanced Persistent Threat 29 — ชื่อรหัสที่วงการให้กับกลุ่มแฮกเกอร์) หรืออีกชื่อ Cozy Bear เป็นกลุ่มที่ทำงานให้ SVR (Sluzhba Vneshney Razvedki — หน่วยข่าวกรองต่างประเทศของรัสเซีย). ไม่ใช่อาชีพหรือเด็กแว้น — เป็น nation-state actor ระดับชาติ มีงบประมาณ มีทีม มีเวลา

ระหว่างปี 2019 ปลายปี APT29 แทรกซึมเข้าระบบของ SolarWinds เอง — เข้าถึง build pipeline (สายการผลิตซอฟต์แวร์ — ระบบที่นักพัฒนาเขียน code → compile → test → เซ็น digital signature → ปล่อยเป็น update ให้ลูกค้าโหลด). โจรไม่ได้เข้าไปขโมยอะไร — โจรเข้าไป ใส่ของลงไป. ฝัง malware ชื่อ Sunburst เข้าไปในซอร์สโค้ดของ Orion ในจังหวะที่ build ตัว update ใหม่

ผลคือ — มีนาคม 2020 SolarWinds ปล่อย Orion update เวอร์ชันใหม่ออกมา ตามรอบปกติ. update ตัวนี้ ผ่าน QA ของ SolarWinds ปกติ ถูกเซ็นด้วย digital signature ที่ถูกต้องของ SolarWinds เอง — ทุกอย่างดู legitimate 100%. ลูกค้าทั่วโลก ~18,000 รายติดตั้ง update นี้ — รวมถึงกระทรวง Treasury, กระทรวง Commerce, กระทรวง State Department, กระทรวง Homeland Security ของสหรัฐ + Microsoft + FireEye + บริษัทอื่นอีกเป็นพันราย

ตรงนี้น่าสนใจ — โจรไม่ได้ใช้ทุก 18,000 ราย. Sunburst ใน Orion update คือ “backdoor ที่หลับอยู่” — มันใช้เวลาประมาณ 2 สัปดาห์หลังติดตั้งก่อนจะเริ่มทำงาน เพื่อหลีกเลี่ยงการตรวจจับช่วงทดสอบ. แล้วมันคุยกับ command-and-control server ของโจรด้วย DNS ที่ดูเหมือนชื่อเซิร์ฟเวอร์ปกติของ SolarWinds — กลมกลืนสุดๆ. APT29 ดูรายชื่อเหยื่อทั้ง 18,000 รายแล้ว เลือกเฉพาะที่อยากเจาะลึก — น่าจะประมาณ 100 องค์กรเท่านั้น — ที่เหลือปล่อยทิ้งเฉย ๆ เพื่อไม่ให้สะดุดตา. คุณเข้าใจไหมครับ — ในมือของกลุ่มนี้ การได้ access 18,000 องค์กรทั่วโลก = “เลือกได้สบายๆ ว่าใครจะโดน”

แล้วโลกรู้เรื่องนี้ได้ยังไง? บังเอิญครับ. ธันวาคม 2020 FireEye (บริษัท cybersecurity ระดับโลก — ใหญ่มาก ลูกค้าเป็นรัฐบาล) ตรวจพบว่ามีคนพยายามขโมย Red Team tools ของตัวเอง. ทีม FireEye สืบกลับ → เจอว่าโจรเข้ามาผ่าน Orion → แจ้ง SolarWinds → แจ้ง CISA (Cybersecurity and Infrastructure Security Agency — หน่วยความปลอดภัยไซเบอร์ของรัฐบาลอเมริกา) → CISA ออกคำสั่งฉุกเฉินภายใน 24 ชั่วโมง ให้ทุกหน่วยงานรัฐบาลกลางอเมริกา disconnect Orion ทันที. เป็นคำสั่งระดับ “ปลดสาย LAN เดี๋ยวนี้” — ระดับฉุกเฉินที่ไม่ค่อยเกิด

ตอนรู้ตัวคือเดือนธันวาคม 2020. update ที่ฝัง Sunburst ออกตั้งแต่มีนาคม. แปลว่าโจรอยู่ในระบบของกระทรวงต่างๆ อเมริกาเกือบ 9 เดือนเต็มก่อนรู้ตัว — ตัวเลขนี้ในวงการเรียกว่า dwell time (เวลาที่โจรอยู่ในระบบโดยที่เจ้าของยังไม่รู้). dwell time 9 เดือนของระดับกระทรวงคืออะไรในชีวิตจริง? คือโจรอ่านอีเมลภายในของกระทรวงทุกฉบับ ดู doc ทุกชิ้น สำรวจระบบทุกซอกของ infrastructure รัฐบาลอเมริกาได้ 9 เดือนแบบไม่มีใครรู้

ค่าเสียหาย? ประเมินยากมากครับ เพราะหลายส่วนเป็น classified ของรัฐบาล. แต่ค่าจัดการเหตุการณ์ (incident response) ทั่วโลก + การ rebuild ระบบที่โดนกระทบ + การสอบสวน — น่าจะ เกินพันล้านดอลลาร์ เมื่อรวมทุกองค์กรเข้าด้วยกัน. SolarWinds เองโดนฟ้องเป็น class action + โดน SEC สอบเรื่องเปิดเผยข้อมูลล่าช้า. CEO ลาออก

lesson ของเคสนี้คือ เชื่อ vendor ไม่ได้ 100% — แม้แต่ digital signature ครับ. Digital signature คือกลไกที่ปกติเรา “เชื่อถือ” ได้ว่า software ตัวนี้มาจาก SolarWinds จริง ไม่ได้ถูกเปลี่ยนกลางทาง — เพราะถ้าใครเปลี่ยน byte เดียว signature จะ invalid. แต่ในเคสนี้ signature ถูกต้อง 100% — เพราะโจรเข้าไปฝัง malware ก่อน ขั้นตอนเซ็น. คือ SolarWinds เซ็นรับรอง malware เองโดยไม่รู้ตัว

ลองนึกภาพง่ายๆ ครับ. เมืองของคุณมี “ผู้สร้างบ้าน” รายใหญ่ที่ทุกหมู่บ้านใหม่ใช้เขาสร้าง — ใบรับรองวิศวกร เอกสารทุกอย่างครบ. ปกติคุณซื้อบ้านใหม่จากเขาก็เข้าอยู่ได้สบายใจ. แต่วันหนึ่ง — ทีมงานคนหนึ่งของบริษัทผู้สร้างถูกแทรกซึม → ทุกบ้านใหม่ที่สร้างในช่วง 3 เดือนนั้น มีท่อแก๊สพิษซ่อนอยู่หลังผนัง. บ้านยังดูปกติ ผ่าน inspection ปกติ ใบรับรองวิศวกรครบ — แต่คนอยู่ในนั้นโดนยาช้าๆ. ลูกค้าทุกคน “เชื่อ” ผู้สร้างถูกต้องตามสามัญสำนึก — เพราะเอกสารครบ — แต่ความเชื่อนั้นล้มเหลว

หรือถ้าจะให้ใกล้ตัวกว่านั้น — ยาที่หมอสั่ง pharmacy ส่งมาที่บ้าน. ปกติเชื่อได้ไหม? เชื่อได้. ตราประทับ pharmacy ปิดผนึกเรียบร้อย ใบเสร็จมี QR ของหมอ. แต่ถ้า pharmacy ถูกแฮก — ยาในขวดเปลี่ยนได้โดยที่ตราประทับยังเหมือนเดิม. ความเชื่อนั้น = ความเชื่อในความปลอดภัยของ pharmacy ไม่ใช่ความเชื่อในยา

นี่คือ supply chain attack ระดับชาติ ครับ — เคสที่กระตุกให้ทุกองค์กรในโลก ตั้งคำถามใหม่ว่า “เราเชื่อ vendor ของเราเพราะอะไร?” — ถ้าคำตอบคือ “เพราะ vendor บอกว่าเขาปลอดภัย” — คำตอบนี้ใช้ไม่ได้แล้วหลัง 2020

มุมผู้บริหาร: ลอง list software ทั้งหมดที่บริษัทคุณติดตั้ง — ไม่ใช่แค่ที่คุณซื้อโดยตรง แต่รวม plugin / extension / library ของนักพัฒนา / SDK ที่ฝังในแอป / โอเพนซอร์สต่างๆ. ทุกตัวคือ “ผู้สร้างบ้าน” คนหนึ่ง. คำถามที่ต้องถาม: “เกิด vendor ตัวไหนของเราถูกแฮก เรารู้ตัวภายในกี่วัน?” — ถ้าคำตอบคือ “ไม่รู้” — แปลว่าคุณอยู่ในตำแหน่งเดียวกับลูกค้า SolarWinds ตอนเช้าวันที่ FireEye ยังไม่ส่งจดหมายมา. คือไม่รู้ว่าโดนแล้วหรือยัง

4 เคส 4 บทเรียน — pattern ที่ซ้ำกัน#

เอาล่ะ 4 เคสจบครับ. ก่อนจะปิด EP นี้ผมอยากให้เราวางทั้ง 4 เคสเรียงกันแล้วถอยมามองภาพรวม — เพราะ pattern ที่อยู่ลึกใต้ทั้ง 4 เคสนี่แหละคือสิ่งที่คุณต้องเอาไปใช้

ก่อนอื่น สรุปบทเรียนของแต่ละเคสครับ:

1. Equifax — Compliance ≠ Security. ผ่าน audit ผ่าน checklist ผ่านมาตรฐานสากล — ไม่ได้แปลว่าโจรปล้นไม่ได้. audit เป็น snapshot, security เป็น continuous. ตัวจริงที่ทำให้พังคือ patch ที่ลืมลง + scanner ตั้งค่าผิด + ขั้นตอนภายในที่ไม่ครบ — ทั้งหมดนี้ checklist ไม่จับ

2. Target — Supply chain คือด่านหน้า. firewall 100 ล้านไม่ช่วย ถ้าคู่ค้ารายเล็กของคุณโดน phishing ก่อน. ความปลอดภัยของคุณ = ความปลอดภัยของ vendor ที่อ่อนแอที่สุดที่คุณเชื่อมต่อด้วย. โจรไม่ปีนกำแพง — โจรเดินตามคนที่มีกุญแจ

3. Capital One — Cloud ตั้งค่าให้ถูก + รู้ว่าคุณรับผิดชอบส่วนไหน. cloud provider ดูแลตึก คุณดูแลห้อง. ปล่อยประตูห้องเปิด → โดนปล้น เจ้าของตึกไม่ผิด. และคนที่รู้ระบบ (insider knowledge) คืออาวุธของอีกฝั่งเสมอ

4. SolarWinds — เชื่อ vendor ไม่ได้ 100% แม้ digital signature. ของจริงตามเอกสารทุกชิ้น ตราประทับครบ — ก็ยังถูกฝัง malware ได้ ถ้าโจรเข้าถึง build server ของ vendor ก่อน. ความเชื่อในยี่ห้อใหญ่ + ความเชื่อในเอกสารทางการ ไม่ใช่ control ที่แท้จริง

ทีนี้ — ถ้าคุณเรียง 4 เคสนี้แล้วถามว่า “จุดร่วมคืออะไร” ผมอยากให้สังเกต 3 จุดนะครับ

จุดร่วมที่ 1 — ไม่มีเคสไหนเกิดจาก “โจรเก่งกว่าระบบ”. ทั้ง 4 เคสเกิดจาก mindset ที่ผิดของบริษัท ทั้งหมด. Equifax คิดว่า audit = ปลอดภัย. Target คิดว่า security คือเรื่องของตัวเองคนเดียว. Capital One คิดว่าใส่ของขึ้น cloud แล้วปลอดภัยอัตโนมัติ. SolarWinds (และ 18,000 ลูกค้า) คิดว่า digital signature = เชื่อได้. โจรไม่ได้เก่งกว่า — โจรแค่ใช้ประโยชน์จาก mindset ผิดของอีกฝั่ง

จุดร่วมที่ 2 — dwell time ยาวมากทุกเคส. Equifax 76 วัน. Target ~3 สัปดาห์ที่ดักข้อมูล (แต่อยู่ในระบบนานกว่านั้น). Capital One หลายเดือน. SolarWinds 9 เดือน. นี่คือตัวเลขที่ผู้บริหารต้องจำ — โจรในเคสจริง ไม่ใช่ “เข้ามาแล้วขโมยรีบหนีในชั่วโมงเดียว” แบบในหนัง. โจรอยู่ในระบบเป็นเดือนเป็นปี ค่อยๆ สำรวจ ค่อยๆ ขยาย ค่อยๆ ขโมยเงียบๆ. คำถามไม่ใช่ “เราป้องกัน 100% ไหม” — คำถามคือ “ถ้าโจรอยู่ในระบบเราตอนนี้ — เราจะรู้ตัวภายในกี่วัน?”

จุดร่วมที่ 3 — “ของแพง” ไม่ช่วย ถ้า “พื้นฐาน” ไม่ครบ. Equifax มี budget security ใหญ่ — แต่ scanner ตั้งค่าผิด + patch ไม่ลง. Target มี FireEye ตัวใหม่ราคาหลายล้าน — แต่ทีม SOC ignore alert. Capital One มี WAF ระดับ enterprise — แต่ตั้งค่า role IAM ผิด + bucket S3 เปิดอ่านกว้างเกิน. SolarWinds — ลูกค้าทั้ง 18,000 ราย มี firewall + EDR + SIEM ครบหมด — ไม่ช่วย เพราะ malware มาผ่าน update ที่ “ถูกเชื่อใจ” จาก vendor. ของแพงไม่ใช่คำตอบ. กระบวนการ + ความเข้าใจพื้นฐาน + การตั้งคำถามที่ถูก = คำตอบ

มุมผู้บริหาร: 4 เคสนี้รวมเป็นคำถามเดียวที่ผู้บริหารต้องถามทีม IT — “ถ้า vendor หรือ component ตัวใดตัวหนึ่งของเราถูกแฮกพรุ่งนี้ — เราจะรู้ตัวภายในกี่วัน?” ถ้าตอบไม่ได้ทันที — ไม่ใช่ความผิดทีม แต่แปลว่าบริษัทยังไม่ได้วาง process ที่จะมีคำตอบ. นั่นคือจุดเริ่มต้น

สรุป — 4 เมืองที่ถูกปล้น 4 รูปแบบ#

ถ้าให้สรุป EP นี้เป็นภาพเดียวครับ — **เมืองในประวัติศาสตร์ cybersecurity ที่ถูกปล้นชื่อดังที่สุด 4 เมือง ไม่ได้พังเพราะกำแพงไม่สูงพอ ไม่ได้พังเพราะปืนใหญ่ไม่แพงพอ. พังเพราะ mindset ที่ผิดของเจ้าเมือง — เชื่อใบรับรองมากเกิน เชื่อคู่ค้ามากเกิน เชื่อ cloud มากเกิน เชื่อ vendor มากเกิน — และโจรเข้ามาทางช่องว่างระหว่างความเชื่อเหล่านั้น

Equifax เชื่อว่าผ่าน audit = ปลอดภัย → โจรเข้าทาง patch ที่ลืมลง. Target เชื่อว่าระบบของตัวเองแน่น → โจรเข้าทางช่างซ่อมแอร์ที่โดน phishing. Capital One เชื่อว่า cloud ปลอดภัยเอง → โจรเข้าทาง role ที่ตั้งค่าผิด. SolarWinds (และลูกค้า 18,000 ราย) เชื่อว่า digital signature = เชื่อได้ → โจรเข้าทาง build server ของ vendor ก่อนถึงขั้นตอนเซ็น

สิ่งที่ผู้นำต้องจำ#

ข้อแรก audit ≠ security, vendor ≠ ปลอดภัยอัตโนมัติ, cloud ≠ ปลอดภัยเอง. สิ่งที่อยู่ระหว่าง “ใบรับรอง” กับ “ความปลอดภัยจริง” คือ กระบวนการต่อเนื่อง — patch ทุกสัปดาห์ ทบทวน access ทุกเดือน scan config cloud ทุก quarter test restore backup ทุก 6 เดือน. กระบวนการพวกนี้ไม่ sexy ไม่อวดได้ — แต่คือสิ่งที่ทำให้บริษัทรอด ส่วน “ของแพงตัวใหม่” คือสิ่งที่ทำให้รายงานต่อบอร์ดดูดี

ข้อสอง dwell time คือ KPI ที่ผู้บริหารต้องดู — ไม่ใช่ “เคยโดนหรือยัง”. เคสจริง dwell time ยาว 3-9 เดือน เป็นเรื่องปกติ — แปลว่าวันนี้คุณอาจจะ “โดนแล้วแต่ยังไม่รู้”. คำถามที่ถูกต้องสำหรับผู้บริหารไม่ใช่ “เราถูกแฮกหรือยัง” (ตอบยากและไม่มีประโยชน์) — แต่คือ “ถ้าโจรเข้ามาตอนนี้ กว่าจะรู้ตัวเฉลี่ยกี่วัน?” ตัวเลขนี้ที่ลดจาก 200 วันเหลือ 30 วันได้ = ลดความเสียหายเฉลี่ยต่อ breach หลายล้านบาท. การลดตัวเลขนี้ต้องลงทุนใน detection (SIEM / EDR / SOC) — ไม่ใช่กำแพงเพิ่ม

4 เคสนี้คือ 4 mindset ที่ต้องเปลี่ยน ครับ — และทุก mindset ที่เห็นล้วนเกิดจากการ “ไม่มีกรอบคิดที่ถูก” ในการตัดสินใจเรื่อง security. ถ้าจะเปลี่ยน mindset เราต้องมีเครื่องมือคิดที่ใช้กรองทุก decision. EP ต่อไปผมจะวางเครื่องมือแรกของชุดนี้ — CIA Triad — 3 คำถามสั้นๆ ที่ทุก control ใน cybersecurity ต้องตอบให้ได้. ถ้า control ใดตอบ 3 คำถามนี้ไม่ได้ → control นั้นไม่จำเป็น. แค่ 3 คำถาม — แต่ใช้กรองได้ตั้งแต่ password ของพนักงานยันสัญญา vendor ระดับชาติ

→ EP.03 — CIA Triad: 3 คำถามที่ทุก control ต้องตอบ (เร็วๆ นี้)