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

ลองนึกภาพ 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 ทุกอันโดยอัตโนมัติ