ตำรวจที่เชื่อว่าไม่มีโจรในเมือง — และเช้าวันที่เมืองถูกปล้น#

ลองนึกภาพ 2 เมืองนี้ครับ

เมือง A — มีตำรวจชุดหนึ่ง เก่งมาก ภูมิใจในเมืองของตัวเอง. หัวหน้าตำรวจประกาศต่อสาธารณะมาตลอด 10 ปี ว่า “เมืองของเราปลอดภัยที่สุดในประเทศ ไม่มีโจรกล้าเข้ามา”. ทุกคืนตำรวจกลับบ้านตามเวลา ไม่มีลาดตระเวน ไม่มีกล้อง CCTV เพิ่ม ไม่มีฝึกซ้อมรับมือเหตุการณ์. งบประมาณส่วนใหญ่ลงไปที่ป้อมยามด่านนอกเมือง — เพื่อ “ไม่ให้โจรเข้ามาได้เลย”

เมือง B — มีตำรวจอีกชุดหนึ่ง. หัวหน้าตำรวจประกาศต่อลูกน้องทุกเช้าว่า “วันนี้มีโจรอยู่ในเมืองของเรา — เราแค่ยังหาไม่เจอ”. ทุกคืนมีตำรวจลาดตระเวน 24 ชั่วโมง มีกล้องเชื่อมเข้าห้องควบคุมกลาง มีการซ้อมรับเหตุทุกเดือน. งบประมาณกระจายระหว่าง “ป้อมยามด่านนอก” + “กล้อง” + “ทีมลาดตระเวน” + “ทีมตอบโต้เหตุฉุกเฉิน” ค่อนข้างเท่าๆ กัน

วันหนึ่ง โจรกลุ่มเดียวกันลองเข้าทั้ง 2 เมือง

เมือง A — โจรหาช่องว่างของป้อมด่านนอกได้ (มีเสมอ — ไม่มีป้อมไหนสมบูรณ์ 100%). พอเข้ามาในเมืองได้ — ไม่มีใครเห็น ไม่มีกล้อง ไม่มีตำรวจลาดตระเวน. โจรเดินไปร้านทอง เดินไปธนาคาร เดินไปสำนักงานเทศบาล เก็บของจนพอใจ ออกประตูเดิม. ตำรวจของเมือง A รู้ตอนเช้าวันถัดไป — “เมืองโดนปล้น” — และก็ยังไม่รู้ว่าโจรเข้าตอนไหน อยู่ในเมืองนานแค่ไหน เอาอะไรไปบ้าง

เมือง B — โจรหาช่องว่างของป้อมด่านนอกได้เหมือนกัน (เพราะเป็นโจรชุดเดียวกัน). แต่พอเข้ามาในเมือง — ตำรวจลาดตระเวนเห็นในเวลา 7 นาที. เสียงไซเรนดัง ทีมตอบโต้ออกมาในเวลา 12 นาที. โจรหนีออกประตูข้างทันที — เก็บได้แค่กระเป๋าตังค์ใบเดียวจากร้านเล็กแห่งแรกที่เดินผ่าน. ตำรวจของเมือง B รู้ภายในวันเดียวกัน — “เมืองโดนพยายามปล้น เสียหายกระเป๋าตังค์ 1 ใบ”

ทั้ง 2 เมือง โจรเข้ามาในเมืองได้เหมือนกัน. แต่ความเสียหายต่างกัน 1,000 เท่า. ความต่างไม่ได้อยู่ที่ “ป้อมด่านนอก” — อยู่ที่ เมือง B สมมติตั้งแต่แรกว่าโจรอยู่ในเมือง ครับ. เลยลงทุนกล้อง + ลาดตระเวน + ทีมตอบโต้ — และพอโจรเข้ามาจริงๆ ระบบเหล่านี้ทำงานทันที

นี่คือหลักการ Assume Breach (สมมติว่าโดนแล้ว — บางคนแปลว่า “ตั้งสมมติฐานว่าโดนเจาะแล้ว”) ครับ. ความหมายตรงตัวคือ ออกแบบทุกระบบในบริษัทโดยสมมติว่า attacker (ผู้โจมตี) ได้สิทธิ์เข้าระบบไปแล้ว — แล้วถามต่อว่า ในสภาพนั้นจะจำกัด damage ยังไง + เห็นได้เร็วแค่ไหน + หยุดได้เร็วแค่ไหน

หลักการนี้ไม่ได้บอกให้เลิกสร้างป้อมนะครับ — ป้อมยังต้องมี Defense in Depth + Diversity ครบจาก EP.04. Assume Breach บอกว่า “นอกจากป้อม คุณต้องลงทุนอีกชั้นที่ทำงานสมมติว่าป้อมพังแล้ว”. เปลี่ยน mindset จาก “ป้องกัน” (prevention) เป็น “ป้องกัน + ตรวจจับ + ตอบโต้” (prevent + detect + respond) ที่สมดุล

ในโลก IT จริง Assume Breach หน้าตาเป็นยังไงครับ? ลองดูตัวอย่างใกล้ตัวที่หลายตัวเราคุยกันใน IT Foundation EP ก่อนหน้านี้ —

Microservices vs Monolith — ที่เราคุยใน IT Foundation EP.04 (Architectures). บริษัทที่ออกแบบระบบเป็น Monolith (ระบบยักษ์รวมศูนย์ทุกฟังก์ชันในตัวเดียว) — ถ้าโจรเข้าได้ที่ฟังก์ชันใดฟังก์ชันหนึ่ง = เข้าได้ทั้งระบบ เพราะทุกอย่างอยู่ในเครื่องเดียว memory เดียว database เดียว. บริษัทที่ออกแบบเป็น Microservices (ระบบแยกย่อยเป็นบริการเล็กๆ คุยกันผ่าน API) — ถ้าโจรเข้า service เดียว ติดอยู่ใน service นั้น ไม่ลามทั้งระบบ. Microservices ไม่ใช่แค่เรื่อง “scale ได้ง่าย” — มันเป็น Assume Breach by design ที่ damage จำกัดในตัวเอง

Network Segmentation (การแบ่งเครือข่ายเป็นโซน) — ที่เราเริ่มเล่าใน EP.04. ถ้าบริษัทมี network แบนๆ ที่ทุกเครื่องคุยกันได้หมด — workstation 1 เครื่องของพนักงานบัญชีโดน malware = workstation นั้นคุยกับ database ของลูกค้าได้ทันที. ถ้าทำ segmentation — workstation อยู่ใน VLAN ของพนักงาน, database อยู่ใน VLAN ของ data, ระหว่าง 2 VLAN มี firewall กั้น ที่อนุญาตเฉพาะ “พนักงาน 3 คนนี้ เข้า table นี้ ในช่วงเวลานี้”. workstation โดน = ติดอยู่ใน VLAN พนักงาน ไม่ถึง database

Zero Trust (ตรวจที่ทุกประตู ไม่ใช่แค่ประตูหน้า) — Zero Trust เป็น mindset ที่เราจะลงลึกใน Part 2 (Identity) ของซีรีส์นี้ครับ. ตอนนี้รู้แค่ว่ามันคือ “ห้ามเชื่อใจใครเลยในระบบ — ไม่ว่าจะอยู่ในป้อมหรือนอกป้อม — ต้องตรวจสอบที่ทุกขั้นทุกประตู”. ตรงข้ามกับ mindset เก่าที่เรียก “castle-and-moat” — สมมติว่าใครก็ตามที่ผ่านป้อมเข้ามาได้ คือคนของบริษัท เชื่อใจได้ทันที. Zero Trust สมมติว่า “ทุกคนที่อยู่ในป้อมอาจเป็นโจรที่ปลอมตัวมา” — ทุกครั้งที่เปิดประตูห้องไหน ต้องแสกนบัตรใหม่ + ยืนยันตัวใหม่ + ตรวจว่าเหตุผลที่จะเข้าสมเหตุสมผลไหม. นี่คือ Assume Breach ที่ลงลึกถึงระดับ identity

เคสที่อยากให้คุณเห็นภาพ Assume Breach ของจริงคือ Google’s BeyondCorp ครับ. ปี 2009 Google โดน operation Aurora — โจรจีน (ที่วงการเชื่อว่ามาจากรัฐบาลจีน) เข้า internal network ของ Google ผ่าน Internet Explorer 6 ของพนักงาน → ขโมย source code ของ Google + ข้อมูลของ activist ชาวจีนที่ใช้ Gmail. Google จะตอบสนองยังไง? บริษัทอื่นจะ “สร้างกำแพงให้สูงขึ้น” — Google ทำตรงข้าม: เลิกใช้กำแพงเลย

Google ออกแบบใหม่ทั้งหมดเรียกว่า BeyondCorp ตามหลัก Zero Trust — ถือว่า “internal network = internet ไม่ต่างกัน”. พนักงาน Google ที่นั่งในออฟฟิศ Mountain View ใช้ Wi-Fi ของบริษัท ไม่ได้สิทธิ์มากกว่าพนักงานที่นั่งที่ร้านกาแฟ Starbucks เลย. ทุก request ที่จะใช้ระบบของ Google ต้องผ่านการตรวจสอบเหมือนกันหมด — ไม่ว่าคุณจะอยู่ “ในป้อม” หรือ “นอกป้อม”. นี่คือ Assume Breach ระดับสุดในการ implement — สมมติเลยว่า internal network = ไม่มีอยู่จริง ทุกคนเป็นโจร จนพิสูจน์ว่าไม่ใช่. และ Google ใช้ระบบนี้ตั้งแต่ปี 2014 จนถึงตอนนี้ — เป็นต้นแบบที่บริษัทใหญ่ทั่วโลกเลียนแบบ

มุมผู้บริหาร: ลองถามคำถามนี้กับทีม IT ของคุณครับ — “สมมติคืนนี้โจรเข้า workstation ของพนักงานบัญชีคนหนึ่งสำเร็จ — ภายใน 24 ชั่วโมงถัดมา โจรจะเข้าถึงข้อมูลอะไรของบริษัทได้บ้าง?”. ถ้าคำตอบคือ “ทุกอย่าง — เพราะ workstation นั้นต่อ network เดียวกับ server ทุกตัว” — แปลว่าบริษัทคุณยังอยู่ใน mindset เก่า (castle-and-moat) ที่ “ในป้อมเชื่อใจกันได้”. ถ้าคำตอบคือ “เข้าได้แค่ไฟล์ที่พนักงานคนนั้นเข้าได้ปกติ + ไม่สามารถข้ามไปยัง VLAN อื่น + ทุก request ยังต้อง 2FA ใหม่” — คุณมี Assume Breach mindset แล้ว. การเปลี่ยนจากแบบแรกเป็นแบบหลัง = project 1-2 ปี + งบประมาณหลักล้าน แต่ลด blast radius (รัศมีของความเสียหายเมื่อโดน) ลง 90%+ และเป็นสิ่งที่ผู้บริหารต้องริเริ่ม ไม่ใช่รอ IT มาเสนอ

ดับเพลิงในเมือง — MTTD / MTTR ตัวเลข 2 ตัวที่ผู้บริหารต้องดูแทน “เราปลอดภัยไหม”#

โอเค สมมติคุณเปลี่ยน mindset เป็น Assume Breach แล้ว — เห็นด้วยว่าโจรจะเข้ามาได้สักวัน. คำถามต่อมาที่หนีไม่พ้นคือ — แล้วเราจะวัดยังไงว่าระบบ Assume Breach ของเราทำงานดี?

คำถามนี้สำคัญมากครับ เพราะถ้าวัดไม่ได้ — ลงทุนไปก็ไม่รู้ว่าได้ผลไหม. และบริษัทไทยส่วนใหญ่ตัดสินใจเรื่อง security จาก “ความรู้สึก” ไม่ใช่ตัวเลข — เช่น “วันนี้ทีม IT บอกว่าระบบของเราปลอดภัย” หรือ “vendor บอกว่าของเราดีที่สุดในตลาด” หรือ “ปีนี้ยังไม่มีอะไรพังนะ น่าจะโอเค”. ฟังดูคุ้นเคยใช่ไหมครับ — เพราะนี่คือวิธีตัดสินใจของ board meeting ส่วนใหญ่

ลองเปลี่ยนเรื่องเปรียบเทียบสักหน่อยครับ — ดับเพลิงในเมือง. ไม่มีนายกเทศมนตรีคนไหนในโลกประกาศว่า “ปีนี้เมืองของเราจะไม่ให้มีไฟไหม้เลย”. ทำไม? เพราะทุกคนรู้ว่าไฟจะไหม้แน่ๆ ในเมืองใหญ่ — เรื่องของเวลาเท่านั้น. ดังนั้นนายกเทศมนตรีที่เก่งคุยกันเรื่องอื่นแทน — คุยเรื่อง “กี่นาทีกว่ารถดับเพลิงจะถึงที่เกิดเหตุ” กับ “กี่นาทีกว่าจะดับไฟได้สนิท”. 2 ตัวเลขนี้คือสิ่งที่นายกเทศมนตรีของเมืองใหญ่ในโลกใช้ benchmark กัน

ในวงการ cybersecurity มี 2 ตัวเลขที่ทำหน้าที่เหมือนกันเป๊ะครับ — MTTD กับ MTTR

MTTD (Mean Time To Detect — เวลาเฉลี่ยที่ใช้ในการตรวจพบ) = ตั้งแต่ที่โจรเข้าระบบครั้งแรก ใช้เวลากี่วันกว่าทีม security จะรู้ว่าโดน. ลองนึกเป็น “กี่วินาทีตั้งแต่ไฟเริ่มไหม้จนถึงตอนที่ตู้แจ้งเหตุดัง”

MTTR (Mean Time To Respond / Recover — เวลาเฉลี่ยที่ใช้ในการตอบโต้และฟื้นฟู) = ตั้งแต่ตอนรู้ ใช้เวลากี่วันกว่าจะหยุดการโจมตี + ฟื้นระบบกลับมาใช้งานได้ปกติ. ลองนึกเป็น “กี่นาทีตั้งแต่ตู้แจ้งเหตุดังจนไฟดับสนิท”

ตัวเลขจริงในโลก security เป็นยังไงครับ? IBM ออกรายงาน Cost of a Data Breach Report ทุกปีจากข้อมูล breach ของบริษัททั่วโลก. ปี 2023 ตัวเลขเฉลี่ยทั่วโลกคือ —

• MTTD = 207 วัน (เกือบ 7 เดือนกว่าทีม security จะรู้ว่าระบบโดน)
• MTTR = 73 วัน (อีกเกือบ 2 เดือนครึ่งกว่าจะหยุด + ฟื้น)
• รวม = 280 วัน = เกือบ 1 ปีเต็ม ตั้งแต่โจรเข้าจนระบบกลับมาปกติ

ลองดูเลขนี้อีกรอบครับ — โจรอยู่ในระบบของบริษัทเฉลี่ย 7 เดือน ก่อนที่ใครจะรู้. 7 เดือนที่โจรเดินเล่นในเมือง อ่านอีเมล ขโมยข้อมูลทีละน้อย ตั้ง backdoor ไว้ในระบบหลายตัว — โดยไม่มีใครเห็น. นี่คือค่าเฉลี่ยทั่วโลก ไม่ใช่ worst case

เคสจริงที่เลขนี้ออกมาน่ากลัวกว่านี้อีกครับ —

SolarWinds 2020 — ที่เราเล่าใน EP.02. โจร (APT29 / Cozy Bear ของรัสเซีย) เข้าระบบ SolarWinds ตั้งแต่กันยายน 2019. โลกรู้ตอนธันวาคม 2020 — dwell time (เวลาที่โจรอยู่ในระบบ) = 14-15 เดือนนับจากตอนเข้าระบบ SolarWinds เอง (ตัวเลข 9 เดือนใน EP.02 นับจากตอน update ที่ฝัง malware ถูกปล่อยออกเดือนมีนาคม 2020 — มุมการนับคนละแบบ แต่เหตุการณ์เดียวกัน). และที่ทุกคนรู้ก็เพราะ FireEye (บริษัท security ที่ตัวเองโดนด้วย) บังเอิญตรวจพบว่ามีคนใช้ token MFA ของพนักงานในที่ผิดปกติ → ขุดต่อ → เจอ malware ใน Orion → ออกประกาศโลก. ถ้า FireEye ไม่บังเอิญเจอ — ใครจะรู้ว่าจะอีกกี่เดือนกว่ามีคนค้นพบ. 18,000 บริษัททั่วโลกที่ใช้ SolarWinds Orion มี malware ฝังอยู่ในระบบเฉลี่ย 1 ปีกว่า — โดยไม่มีใครเห็น

Marriott 2018 — เครือโรงแรม Marriott ประกาศข่าว breach ในเดือนพฤศจิกายน 2018. ข้อมูลลูกค้า 500 ล้านบัญชีหลุด — รวมเลขหนังสือเดินทาง, เลขบัตรเครดิต, ประวัติการเข้าพัก. dwell time ของเคสนี้คือ — โจรอยู่ในระบบ Starwood (ที่ Marriott ซื้อกิจการเข้ามา) ตั้งแต่ปี 2014. 4 ปีเต็ม. ใช่ครับ 4 ปี. ในระหว่างนั้น Marriott ทำ M&A (merger & acquisition — การควบรวมกิจการ) เข้ามาด้วย — Marriott ซื้อ Starwood ปี 2016 โดยไม่รู้ว่ามีโจรอยู่ในระบบ Starwood แล้ว 2 ปี. การ due diligence (ตรวจสอบสถานะกิจการก่อนซื้อ) ที่จ่ายค่าที่ปรึกษากันเป็นล้านดอลลาร์ — มองไม่เห็น

จุดที่น่ากลัวของ MTTD ในเลขเฉลี่ย 207 วัน — มันไม่ใช่ “โจรไม่ทำอะไร” ในช่วงนั้น. ใน 207 วัน โจรมีเวลาทำทุกอย่าง: lateral movement (เคลื่อนตัวจาก system หนึ่งไปอีก system), data exfiltration (ทยอยขโมยข้อมูลออกแบบไม่ให้เห็น traffic spike), persistence (ฝัง backdoor หลายตัวกระจายในระบบเพื่อกลับมาได้ตลอด), staging (เตรียมการสำหรับ ransomware เป็นเดือน). ที่บริษัทประกาศ “เราโดน ransomware เมื่อวาน” — ของจริงโจรเตรียมการ 7 เดือนก่อน

แล้วถ้าลด MTTD ลงได้ คุ้มแค่ไหนครับ? IBM 2023 รายงานว่า — บริษัทที่ลด MTTD จาก 207 วัน → ต่ำกว่า 200 วัน ลด damage เฉลี่ยต่อ breach ได้ $1.76 ล้านดอลลาร์. หมายความว่าถ้าคุณลงทุน detection capability เพื่อลด MTTD ลงแม้แค่ 7 วัน — ROI เป็น 100x+ ของเงินที่ลงทุน. แต่บริษัทไทยส่วนใหญ่ยังใช้งบ security 80%+ ไปที่ prevention (ป้อมด่านนอก) และเหลือแค่ 20% หรือต่ำกว่าไปที่ detection + response — ผิดสัดส่วนตรงข้ามกับสิ่งที่ตัวเลขบอก

มันคล้ายกับเมืองที่ใช้งบ 80% ไปสร้างกำแพงรอบเมือง + 20% ไปที่ตำรวจในเมือง ทั้งที่ในประวัติศาสตร์ทุกเมืองที่อยู่รอดได้นาน — ใช้สัดส่วนกลับกัน. ลงทุนตำรวจในเมืองมากกว่าลงทุนกำแพง เพราะ “วันที่กำแพงพัง” คือเรื่องของเวลา ไม่ใช่ความเป็นไปได้

มุมผู้บริหาร: Meeting ครั้งหน้ากับ CISO — เลิกถาม “เราปลอดภัยไหม?” (คำตอบจะเป็น “ปลอดภัยครับ” เสมอ ไม่บอกอะไร). ถามแทนว่า “MTTD + MTTR ของเราเฉลี่ยกี่วัน เทียบกับ benchmark โลก (207 / 73)?” ถ้าทีมตอบไม่ได้ — แปลว่าบริษัทยังไม่ได้บริหาร security ด้วยตัวเลข ยังอยู่ใน “ความรู้สึก” mode. และตามด้วย — “งบ security ปีนี้สัดส่วน prevention/detection/response เป็นเท่าไหร่?” ถ้าเป็น 80/15/5 = ผิด — แนวทาง Assume Breach คือ 40/40/20

คนซื้อประกันรถ — Risk = Likelihood × Impact#

โอเค ตอนนี้คุณรู้แล้วว่าต้อง Assume Breach + วัด MTTD/MTTR. คำถามต่อมาที่ตามมาเสมอคือ — “งบ security มีจำกัด — แล้วจะลงทุนตรงไหนก่อน?”

นี่คือคำถามที่กรรมการบริษัทไทยส่วนใหญ่ตอบผิด ครับ — ปกป้องของทุกชิ้นเท่ากัน. ผลคือเปลือง + ผิดที่. ปกป้องเว็บแสดงสินค้าที่ไม่มีข้อมูลลูกค้าด้วยงบเท่ากับระบบจ่ายเงิน. ลงทุน firewall ขั้นเทพให้ office network แต่ปล่อย HR system + payroll system ที่มีข้อมูลพนักงานพันคนหละหลวม. นี่ไม่ใช่ security — นี่คือการกระจายงบแบบไม่คิด

วิธีคิดที่ถูกต้องของวงการมีสูตรเดียวครับ — Risk = Likelihood × Impact

อ่านเป็นภาษาคน — “ความเสี่ยงของการป้องอะไรสักอย่าง = โอกาสที่มันจะโดน × ความเสียหายถ้าโดน”. และวิธีที่ดีที่สุดในการเข้าใจสูตรนี้ — ไม่ต้องเป็น IT ก็เข้าใจได้ทันที — คือลองนึกถึง คนซื้อประกันรถ ครับ

ลองคิดเป็นภาพดู — คุณซื้อประกันรถยนต์ บริษัทประกันคิดเบี้ยให้คุณยังไงครับ? เขาไม่ได้คิดจาก “รถคันนี้แพงเท่าไหร่” อย่างเดียว ไม่ได้คิดจาก “คุณขับดีไหม” อย่างเดียว — เขาคิดจาก 2 ตัวรวมกัน:

• Likelihood (โอกาสชน) — ขึ้นกับยี่ห้อรถ ประวัติคนขับ พื้นที่ใช้รถ ฤดูกาล อายุคน. รถสปอร์ตคันแดงของวัยรุ่นในกรุงเทพ → Likelihood สูง. รถเก๋งครอบครัวของคนวัย 50 ในต่างจังหวัด → Likelihood ต่ำ
• Impact (ค่าซ่อม / ค่าทดแทน ถ้าชน) — ขึ้นกับมูลค่ารถ ค่าอะไหล่ ค่าแรงช่าง. Ferrari → Impact สูงมาก (อะไหล่นำเข้า ค่าซ่อมหลักล้าน). Toyota Vios → Impact ต่ำ

ผลคือเบี้ยประกันของ Ferrari ของวัยรุ่นในกรุงเทพ = สูงมาก (Likelihood สูง × Impact สูง). เบี้ยประกัน Toyota Vios ของคนแก่ในต่างจังหวัด = ต่ำมาก (Likelihood ต่ำ × Impact ต่ำ). บริษัทประกันไม่ได้คิดเบี้ย “ตามใจ” — เขาคิดตามสูตร Risk = Likelihood × Impact ที่ใช้กันมา 200 ปี

ในโลก IT คุณคิด เหมือนกันเป๊ะ ครับ. ของแต่ละชิ้นในบริษัทคุณมี Likelihood × Impact ต่างกัน — และคุณต้องลงทุนตามผลคูณนั้น ไม่ใช่ลงทุนเท่ากันหมด

ลองดู decision matrix 4 ช่องครับ —

Likelihood สูง + Impact สูง → ปกป้องสุดชีวิต. ตัวอย่าง: admin account ของ Facebook Page หลักของบริษัทที่มี follower ล้านคน. Likelihood สูง (โจรในไทยล่า admin Facebook Page ดังตลอดเวลา — เห็นในข่าวทุกเดือน). Impact สูง (โดนยึด page → คู่แข่งโพสต์แทน, brand เสียหาย, แอดมินตัวจริงถูก ban ออก, การกู้คืนใช้เวลาเป็นเดือนและไม่การันตี). Action: ทุก admin ต้อง MFA แบบ hardware key, แยก device จากการใช้งานทั่วไป, มี backup admin หลายคน, ตั้ง notification ทุกครั้งที่มี login จาก device แปลก. งบที่ลงตรงนี้ไม่เปลือง — เพราะของชิ้นนี้คือทรัพย์สินที่แท้จริงของบริษัท

Likelihood ต่ำ + Impact สูง → ปกป้องเข้ม. ตัวอย่าง: ระบบจ่ายเงินเดือนพนักงาน (payroll). Likelihood ต่ำ เพราะมีน้อยคนที่รู้ว่าระบบนี้อยู่ตรงไหน + ไม่ได้เปิด internet โดยตรง. แต่ Impact สูงมาก — ถ้าโดนแก้ตัวเลข พนักงานทั้งบริษัทได้เงินผิด, ถ้าโดนขโมยข้อมูล PDPA ผิด, ถ้าโดน ransomware พนักงานไม่ได้เงินเดือนตรงเวลา = ลาออกครึ่งบริษัท. Action: encrypt ข้อมูลแน่นหนา, access control เข้มงวด, backup รายวัน, audit log ทุก transaction. ไม่ต้องลงทุนเท่ากับ Facebook Page (เพราะ Likelihood ต่ำกว่า) — แต่ลงทุนหนักในด้าน Integrity + Backup

Likelihood สูง + Impact ต่ำ → ปกป้องบ้าง. ตัวอย่าง: เว็บแสดงสินค้าของบริษัท ที่ไม่มีระบบ login ไม่มีข้อมูลลูกค้า. Likelihood สูง (เว็บเปิดให้โลกเข้า — โจรเขียน script scan เว็บที่มี vulnerability ทั้งโลกตลอดเวลา). แต่ Impact ต่ำ — โดน deface (เปลี่ยนหน้าเว็บเป็นข้อความโจร) = bring เว็บกลับขึ้นใหม่ใน 2 ชั่วโมง + เปลี่ยน password admin. ไม่มีข้อมูลลูกค้าหลุด, ไม่มีเงินหาย. Action: WAF (Web Application Firewall) พื้นฐาน + monitoring + backup. ไม่ต้องจ้าง pentest ราคา 5 ล้านต่อปีให้กับเว็บแสดงสินค้า

Likelihood ต่ำ + Impact ต่ำ → อย่าเสียเวลา. ตัวอย่าง: เครื่องพิมพ์เก่าในห้องสำเนาที่ต่อ network แต่ไม่ได้ใช้แล้ว 2 ปี. Likelihood ต่ำ (โจรไม่เห็นเครื่องพิมพ์เป็นเป้าโจมตี). Impact ต่ำ (ถ้าโดน — ก็แค่เครื่องพิมพ์พัง ไม่ใช่ทรัพย์สินอะไร). Action: ตัด network ของเครื่องนี้ออก + ถอดสายไฟ. งบ = 0 บาท + เวลา 5 นาที. ไม่ต้องลงทุน EDR ให้กับเครื่องพิมพ์เก่า — ยิ่งลงทุนเท่ากับเครื่อง critical ยิ่งเปลือง

ผมต้องเตือนเรื่องหนึ่งที่เป็น pattern คลาสสิคของวงการที่บริษัทไทยติดบ่อยมากครับ — บริษัทไทยส่วนใหญ่ลงทุน security ผิดที่ในมิติ Likelihood × Impact

ตัวอย่างที่เห็นบ่อย: บริษัทขนาดกลางบริษัทหนึ่งใช้งบหลักล้านปกป้อง office network — firewall ดี, segmentation ครบ, monitoring 24 ชั่วโมง. แต่ระบบ HR + payroll ที่อยู่ในเครื่อง server เก่าตัวหนึ่งในห้อง IT — password ของ admin คือ “Admin@2020”, ไม่มี MFA, ไม่มี backup นอก site, ไม่มี audit log. ทำไม? เพราะ “ระบบ HR เป็นเรื่องในบริษัท ไม่มีใครอยากแฮก HR หรอก”

สมมตินะครับ — สมมติว่าจริง — โจรจะแฮก HR ไปทำไม? คำตอบมีหลายข้อ. (1) ข้อมูลพนักงาน 500 คน — เลขบัตรประชาชน, เลขบัญชีธนาคาร, เงินเดือนแต่ละคน → ขายในตลาดมืดหรือใช้ทำ identity theft ในคนที่ไม่รู้ตัว. (2) แก้บัญชีปลายทางของเงินเดือน — เดือนถัดไปเงินเดือนของพนักงาน 500 คนถูกโอนเข้าบัญชีโจร (BEC แบบที่เราเล่าใน EP.03 — แต่ระดับบริษัท). (3) ใช้ HR system เป็นจุดข้ามไปยังระบบบัญชีหลัก (lateral movement). Likelihood ไม่ได้ต่ำเท่าที่คนใน org คิด — โจรในไทยรู้จัก attack surface นี้ดีและโจมตีบ่อยมากในช่วง 2-3 ปีที่ผ่านมา

ในขณะที่ Impact ของ HR breach ในบริษัทไทย สูงกว่าที่ผู้บริหารคิด เพราะกฎหมาย PDPA ในไทยให้ค่าปรับสูงสุด 5 ล้านบาทต่อกรณี + ค่าเสียหายต่อพนักงานแต่ละราย. บริษัท 500 คน HR breach = ค่าปรับ PDPA + ค่า lawsuit จากพนักงาน + ค่ากู้คืน + แบรนด์เสียหาย = หลักสิบล้าน

จุดที่บริษัทไทยตก: เห็น “office network” คือของแพง → ลงทุนตรงนั้น. เห็น “HR” คือของในบริษัทธรรมดา → ลงทุนน้อย. ของจริงในมิติ Likelihood × Impact ผิดทาง — HR risk สูงกว่า office network risk ในเชิงตัวเลข แต่ลงทุนตรงข้าม

ทางออกที่บริษัทใหญ่ทั่วโลกใช้คือทำสิ่งที่เรียกว่า Risk Register ครับ — แปลตรงตัวว่า “ทะเบียนความเสี่ยง” หรือเรียกแบบเข้าใจง่ายว่า “รายการของในเซฟดิจิทัล + ความเสี่ยงของแต่ละชิ้น”. ลักษณะของ Risk Register เป็นตารางครับ —

ตารางแบบนี้ไล่ของ asset ทั้งหมดในบริษัท + ให้คะแนน 1-5 ในแต่ละด้าน → คะแนนรวมบอกว่าควรลงทุนตรงไหน. ฟังดูง่าย — แต่บริษัทไทย 90% ไม่เคยทำตารางนี้. ผลคือลงทุน security แบบ “ความรู้สึก” และผิดที่เสมอ

มุมผู้บริหาร: ลองทำ exercise นี้กับทีมในเสาร์-อาทิตย์นี้ครับ — เปิด Excel หน้าใหม่ — list 10 อย่างที่สำคัญที่สุดในบริษัทคุณ (ข้อมูล / ระบบ / บัญชี social media / สัญญา). แต่ละข้อให้คะแนน Likelihood (1-5) + Impact (1-5) แล้วคูณกันเป็น Risk Score. เรียงจาก score สูงไปต่ำ. ทีนี้เปิด budget security ปีนี้ของคุณ — ดูว่างบไปที่ของอันดับ 1-3 ของ list นี้กี่ %, ของอันดับ 4-7 กี่ %, ของอันดับ 8-10 กี่ %. ถ้าสัดส่วนไม่ตรงกับ Risk Score — แปลว่าคุณลงทุนผิดที่อยู่ตอนนี้. การปรับสัดส่วนงบให้ตรงกับ Risk Score ทำได้ใน 1 เดือน + ไม่ต้องเพิ่มงบเลย — แค่ย้ายงบจากของ score ต่ำไปของ score สูง — และเปลี่ยน security posture ของบริษัททั้งหมด

ทำไม “100% Security” คือเป้าที่ทำให้บริษัทเลือกผิด — และ Risk Treatment 4 ทาง#

ถึงตรงนี้คุณมีเครื่องมือคิดครบแล้วครับ — Assume Breach + MTTD/MTTR + Risk Register. แต่ผมต้องตอบคำถามใหญ่ที่ค้างใจมาตั้งแต่ EP.01 — “ทำไมไม่ตั้งเป้าให้ปลอดภัย 100% ไปเลย?”

คำตอบสั้นๆ คือ — “ปลอดภัย 100%” เป็นเป้าที่เป็นไปไม่ได้ และที่แย่กว่านั้น มันเป็นเป้าที่ทำให้บริษัทเลือกผิด ครับ. ลองคิดเป็นเรื่องเปรียบเทียบดู

ถ้านายกเทศมนตรีของเมืองหนึ่งประกาศว่า “ปีนี้เมืองของเราจะปลอดภัย 100% — ไม่มีโจรเลย” — เขาจะทำอย่างไร? คำตอบเดียวที่บรรลุเป้าได้คือ — ปิดเมือง. ปิดประตูทุกบาน ห้ามใครเข้า ห้ามใครออก ไม่มีนักท่องเที่ยว ไม่มีคนนอกมาทำการค้า ไม่มี supplier ส่งของเข้ามา. ผลคือ — ปลอดภัย 100% ครับ จริง — แต่ เมืองตาย. ไม่มีคนมาซื้อขาย ไม่มีภาษีเข้าเทศบาล ไม่มีงาน ประชากรย้ายออกหมด

ในธุรกิจคุณก็เหมือนกันครับ. ถ้าคุณตั้งเป้าให้บริษัท “ปลอดภัย 100%” คุณต้อง — ตัด internet, ไม่ให้พนักงาน work from home, ห้าม USB, ห้าม email ภายนอก, ห้ามใช้ cloud, ห้ามต่อ API กับ partner ใดๆ, ทุก transaction ต้อง approve manually 3 คนก่อน. บริษัทคุณปลอดภัย 100% — และไม่มีรายได้. หรือเลือกง่ายกว่า — เลิกธุรกิจไปเลย ก็ปลอดภัย 100% เช่นกัน

มันคือ Security คือ trade-off กับ business เสมอ ครับ. คุณไม่สามารถได้ทั้ง “ปลอดภัยสุด + business เดินสุด” ในจุดเดียวกัน — เหมือนคุณไม่สามารถได้ทั้ง “ขับรถเร็วสุด + ปลอดภัยสุด” ในเวลาเดียวกัน. นายช่างที่ดีไม่ขาย “เร็วสุด + ปลอดภัยสุด” — เขาขาย “เร็วเหมาะกับความปลอดภัยที่รับได้”. CISO ที่ดีก็เหมือนกัน

แล้วเป้าที่ถูกต้องของ security คืออะไรครับ? เปลี่ยนเป้าใหม่ — ไม่ใช่ “ไม่ให้มี breach” เพราะเป็นไปไม่ได้. เป้าใหม่คือ 3 ข้อนี้แทน —

• Breach แล้ว detect เร็ว — ใช้ MTTD เป็นตัววัด. เป้าควรเป็น “ต่ำกว่า 30 วัน” สำหรับบริษัทขนาดกลาง (vs โลกที่ 207 วัน)
• Damage จำกัด — Assume Breach + segmentation + Zero Trust ทำให้โจรที่เข้ามาได้ ไปได้ไกลแค่ “ห้องที่เขาเข้าได้” ไม่ใช่ “ทั้งเมือง”
• Recover ได้ — มี backup + DR plan ที่ทดสอบจริง. ใช้ MTTR เป็นตัววัด. เป้าควรเป็น “ระบบกลับมาภายใน 24 ชั่วโมง” สำหรับระบบ critical, “1 สัปดาห์” สำหรับระบบทั่วไป

3 เป้านี้บรรลุได้จริง — ต่างจาก “ปลอดภัย 100%”. และเมื่อคุณยอมรับว่า “breach จะเกิด” — คำถามต่อมาที่ตามมาเลยคือ — “แล้วในของแต่ละชิ้นในบริษัท เราจะจัดการกับ risk ยังไง?”. ตรงนี้วงการมีสูตรชัดเจน เรียกว่า Risk Treatment 4 ทาง ครับ

ลองนึกภาพคุณมีของในบ้านชิ้นหนึ่งที่มีความเสี่ยงจะหาย — เช่นกระเป๋าถือใบโปรด. คุณมีทางเลือก 4 ทาง:

1. Mitigate (ลด — ใส่ control เพื่อลดความเสี่ยง). ใส่กุญแจตู้, ติดกล้อง CCTV, จ้างยาม. ลด Likelihood ที่จะหาย + ถ้าหายจะรู้เร็ว. ในโลก IT: ติด firewall, EDR, MFA, encryption — สูตรนี้คือสิ่งที่บริษัทไทยใช้กับทุกความเสี่ยงโดยอัตโนมัติ

2. Accept (ยอมรับ — รู้ว่าเสี่ยงแต่ตัดสินใจไม่ทำอะไร). กระเป๋าใบนี้ราคา 500 บาท ค่ากุญแจตู้ 5,000 บาท — Accept ดีกว่า. ถ้าหายก็หาย. ในโลก IT: เครื่องพิมพ์เก่าในห้องสำเนาที่ Likelihood × Impact ต่ำ — รับ risk ที่จะโดน ดีกว่าเสียเงินซื้อ EDR ให้เครื่องพิมพ์

3. Transfer (โอน — เอาความเสี่ยงไปให้คนอื่นรับแทน). ซื้อประกัน — ถ้ากระเป๋าหาย บริษัทประกันจ่ายให้. ในโลก IT: ซื้อ Cyber Insurance (ประกันภัยทางไซเบอร์) ที่จ่ายให้คุณเวลาโดน ransomware / data breach / business interruption. หรือ outsource ระบบที่ไม่ถนัดให้ third-party — เช่น ใช้ Stripe จัดการ payment แทนที่จะเก็บเลขบัตรเครดิตเอง = transfer risk ของการเก็บข้อมูลบัตรไปให้ Stripe ที่มีระบบ PCI DSS ดีกว่าบริษัทคุณ

4. Avoid (หลีกเลี่ยง — เลิกทำกิจกรรมที่ก่อให้เกิดความเสี่ยงไปเลย). ไม่ซื้อกระเป๋าใบนี้ตั้งแต่แรก → ไม่มี risk. ในโลก IT: ตัดสินใจไม่เก็บเลขบัตรประชาชนของลูกค้าเลย → ไม่มี risk ของการถูกฟ้อง PDPA. ตัดสินใจไม่เปิด online payment เอง → ไม่มี risk ของการโดน BEC. หรือตัดสินใจเลิก product line ที่มี attack surface สูงเกินไป — เป็นทางเลือกที่กล้าหาญแต่บางครั้งถูกต้องที่สุด

ลองนึก scenario นี้ครับ — บริษัท SME หนึ่งตัดสินใจ Avoid แทน Mitigate กับเรื่องการเก็บเลขบัตรเครดิตของลูกค้า. เดิมพวกเขาเก็บเลขบัตรเครดิตเองในระบบของบริษัท เพื่อให้ลูกค้าซื้อง่ายในรอบถัดไป. เห็นความเสี่ยง PCI DSS + ค่าลงทุนระบบป้องกันที่สูง — เลือก Avoid: เปลี่ยนระบบให้ผ่าน Stripe (ที่ tokenize เลขบัตรแทน) ทันที. ผลคือ — risk ของ data breach เรื่องบัตรเครดิตหายไป 100% ทันที (เพราะไม่ได้เก็บเอง) + ค่าระบบลดลงครึ่งหนึ่ง + ค่า compliance audit ลดลง 70%. การ Avoid ทำได้ดีกว่า Mitigate ในกรณีนี้

ผมเตือนเรื่องที่บริษัทไทยตกบ่อยที่สุดในเรื่อง Risk Treatment ครับ — บริษัทไทย default เป็น Mitigate ทุกอย่าง. ทุก risk ที่เจอ — คำตอบเดียวคือ “ลงทุนซื้อของเพิ่มเพื่อลดความเสี่ยง”. ผลคือ:

• งบ security เพิ่มทุกปี ไม่เคยลด
• ของในเซฟดิจิทัลเยอะเกิน (เก็บทุกอย่างไว้ “เผื่อใช้”) → attack surface ใหญ่ขึ้น → risk เพิ่ม
• บริษัทไม่เคยใช้ Cyber Insurance (Transfer) เพราะรู้สึก “ไม่จำเป็น”
• ไม่เคย Avoid อะไรเลย เพราะถือว่า “เลิกทำคือยอมแพ้”

ลองคิดในมุมกลับครับ — ทุก risk ในบริษัทของคุณ ควรเลือก 1 ใน 4 ทางอย่างมีสติ ไม่ใช่ default เป็น Mitigate ทุกอัน. บางครั้ง Accept ดีกว่า (เพราะ Impact ต่ำเกินกว่าค่า control). บางครั้ง Transfer ดีกว่า (Cyber Insurance + outsource). บางครั้ง Avoid ดีกว่า (เลิกเก็บข้อมูลที่ไม่ใช้). ที่เหลือค่อย Mitigate

มุมผู้บริหาร: ลองดู Risk Register ของบริษัทคุณ — ถ้า 9 ใน 10 แถวเลือก Mitigate แปลว่าไม่ได้ใช้ตัวเลือกอื่นเลย → กำลังเสียเงินมากกว่าที่ควร. ลองท้าทายทีละแถวด้วยคำถามเดียว — “อันนี้ Accept ได้ไหม / Transfer ผ่าน Cyber Insurance ได้ไหม / Avoid ได้ไหม (เลิกเก็บข้อมูลที่ไม่จำเป็น)?” การถามคำถามนี้กับทุกแถวลด security budget ได้ 20-30% โดย posture ไม่แย่ลง — เพราะหยุดเสียเงินไปกับ Mitigate ของที่ไม่ควร Mitigate

สรุป — Part 0 จบแล้ว และเครื่องมือคิด 3 อันที่จะใช้ต่อทั้งซีรีส์#

ถ้าให้สรุป EP นี้เป็นภาพเดียวครับ — ในเมืองที่โจรจะเข้ามาได้สักวัน ป้อมที่ดีที่สุดในประวัติศาสตร์ไม่ใช่ป้อมที่กำแพงสูงสุด แต่คือป้อมที่สมมติว่าโจรอยู่ในนี้แล้ว — มีตำรวจลาดตระเวน 24 ชั่วโมง วัดเวลาที่ตรวจพบ + ตอบโต้ และลงทุนงบป้องกันตาม Likelihood × Impact ของของแต่ละชิ้น ไม่ใช่ตามความรู้สึก. 4 หลักการนี้คือ Assume Breach + MTTD/MTTR + Risk = Likelihood × Impact + Risk Treatment 4 ทาง — เครื่องมือสุดท้ายของ Part 0 ที่จะใช้กรองทุก decision เรื่อง security ของบริษัทคุณตั้งแต่วันนี้

Assume Breach ตอบคำถามว่า “จะออกแบบเมืองยังไงสำหรับวันที่โจรเข้ามาแล้ว” — สมมติเข้าแล้ว ออกแบบให้ damage จำกัด + เห็นเร็ว + หยุดเร็ว. Google’s BeyondCorp ทำให้เห็นว่าบริษัทระดับโลกเปลี่ยน mindset จาก “เชื่อใจ internal network” เป็น “ไม่เชื่อใจใคร ตรวจที่ทุกประตู” และเปลี่ยนทั้งวงการ. MTTD/MTTR ตอบคำถามว่า “แล้วเราจะวัดยังไงว่า Assume Breach ของเราทำงาน” — 207 วัน vs 30 วัน คือคำตอบเชิงตัวเลข. SolarWinds (14 เดือน) + Marriott (4 ปี) ทำให้เห็นว่าเลขเฉลี่ยโลกยังเลวร้ายกว่าที่คิด. Risk = Likelihood × Impact ตอบคำถามว่า “งบมีจำกัด ลงตรงไหนก่อน” — สูตรเดียวกับคนซื้อประกันรถใช้กันมา 200 ปี + Risk Register ที่เปลี่ยน security จาก “ความรู้สึก” เป็น “ตัวเลข”. Risk Treatment ตอบคำถามว่า “แล้วของแต่ละชิ้นทำยังไงต่อ” — Mitigate / Accept / Transfer / Avoid 4 ทาง เลือกอย่างมีสติ ไม่ Mitigate ทุกอันโดยอัตโนมัติ