5 · การป้องกันที่มีหลักฐาน
ภาคนี้ถามคำถามเดียวกับการป้องกันทุกแบบ วัดแล้วได้เท่าไร คำถามสั้นแค่นี้ตอบยากกว่าที่ควรจะเป็น เพราะการป้องกันจำนวนมากที่องค์กรจ่ายเงินซื้ออยู่ทุกปี ไม่เคยมีใครเอาตัวเลขก่อนกับตัวเลขหลังมาวางไว้ข้างกัน มีแต่คำชมและอัตราที่ผู้ขายพิมพ์ให้ดูเอง การป้องกันที่มีตัวเลขก่อนและหลังตีพิมพ์ไว้ จึงอยู่เหนือการป้องกันที่ทุกคนชม เหตุผลอยู่ที่สันของเล่ม — ธรรมชาติไม่ปรับตัว ศัตรูปรับตัว การป้องกันที่ไม่เคยถูกวัดกับผู้โจมตีจริง อาจกำลังกันสิ่งที่ผู้โจมตีเลิกทำไปแล้ว และไม่มีทางรู้จนกว่าจะมีคนนับ
กฎรหัสผ่านที่ผิดมาสามสิบปี · 2017–2025
กฎรหัสผ่านที่คนทำงานทั้งรุ่นท่องได้ขึ้นใจมีอยู่สองข้อ ต้องผสมตัวพิมพ์ใหญ่ ตัวเลขและสัญลักษณ์ และต้องเปลี่ยนใหม่ตามรอบเวลา ทั้งสองข้อไม่ได้มาจากการนับรหัสผ่านที่ถูกเจาะจริง มันมาจากแบบจำลองความสุ่มที่คำนวณบนกระดาษ แล้วมันอยู่ในนโยบายขององค์กรทั่วโลกมาสามสิบปี
เดือนมิถุนายน 2017 NIST ตีพิมพ์ SP 800-63B และลดกฎบังคับผสมตัวอักษรในรหัสผ่านลงเหลือคำว่า SHOULD NOT — ไม่ใช่ห้าม แต่เป็นคำแนะนำว่าไม่ควรทำ พร้อมกำหนดความยาวขั้นต่ำ 8 ตัวอักษร
ข้อความจริงในมาตรา 5.1.1.2 ระบุว่าผู้ตรวจสอบ SHOULD NOT บังคับกฎผสมตัวอักษร และ SHOULD NOT บังคับเปลี่ยนรหัสผ่านตามรอบเวลา แต่ SHALL บังคับเปลี่ยนเมื่อมีหลักฐานว่ารหัสผ่านรั่ว สิ่งที่ใส่เข้ามาแทนบอกทิศทางได้ชัดกว่าสิ่งที่ถอดออก คือความยาว blocklist ของรหัสผ่านที่เคยรั่วแล้ว จำกัดจำนวนครั้งที่ลองผิด และต้องยอมให้วาง (paste) ได้เพื่อให้ password manager ทำงาน ห้าม truncate รหัสผ่าน และควรรับได้ถึง 64 ตัวอักษร ของเก่าคุมสิ่งที่ผู้ใช้พิมพ์ ของใหม่คุมสิ่งที่ผู้โจมตีลองได้
เหตุผลที่ NIST ให้อยู่ในภาคผนวก A และเป็นเหตุผลทางพฤติกรรม ไม่ใช่คณิตศาสตร์ ผู้ใช้ตอบสนองต่อกฎผสมตัวอักษรในแบบที่คาดเดาได้ ความสุ่ม (entropy) ที่กฎดูเหมือนจะซื้อมา จึงไม่ใช่ความสุ่มที่ผู้โจมตีเจอจริง กฎเดิมเผื่อความปลอดภัยไว้บนแกนที่ผู้โจมตีไม่ได้เดิน เพราะผู้ใช้ปรับตัวเข้าหากฎ และผู้โจมตีปรับตัวเข้าหาผู้ใช้ NIST จึงย้ายไปใช้แบบจำลองที่วัดจากรหัสผ่านที่รั่วแล้ว ประโยคที่มักถูกยกมาอ้างจากภาคผนวกนั้นตรวจกับต้นฉบับโดยตรงไม่ได้ในการค้นคว้าครั้งนี้ เล่มนี้จึงอ้างเฉพาะมาตรา 5.1.1 ที่อ่านจากต้นฉบับ
สองความเชื่อที่แพร่อยู่ตายในการค้นคว้า ข้อแรก "NIST ห้ามกฎรหัสผ่านซับซ้อนตั้งแต่ 2017" — ไม่จริง ปี 2017 เป็นแค่ SHOULD NOT คำว่า SHALL NOT มาถึงในฉบับแก้ไขครั้งที่ 4 ที่ประกาศใช้จริงวันที่ 31 กรกฎาคม 2025 ข้อสอง "ฉบับแก้ไขครั้งที่ 4 ออกในปี 2024" — ไม่จริงเช่นกัน ร่างสาธารณะฉบับแรกออก 16 ธันวาคม 2022 ร่างที่สอง 21 สิงหาคม 2024 ฉบับจริง 31 กรกฎาคม 2025 ผู้ขายซอฟต์แวร์ที่อ้างว่าทำตามมาตรฐานปี 2024 กำลังอ้างร่าง
ฉบับที่ 4 ยกคำแนะนำเดิมขึ้นเป็นข้อบังคับ ห้ามกฎผสมตัวอักษร ห้ามบังคับเปลี่ยนตามรอบ และยกความยาวขั้นต่ำเป็น 15 ตัวอักษรสำหรับรหัสผ่านที่ใช้เป็นปัจจัยเดียว 8 ตัวใช้ได้เฉพาะเมื่อรหัสผ่านเป็นหนึ่งในหลายปัจจัย พร้อมข้อสังเกตใหม่ว่า blocklist ที่ใหญ่เกินไปได้ประโยชน์เพิ่มน้อย เพราะมันกันการโจมตีแบบ online ที่การจำกัดจำนวนครั้งกันอยู่แล้ว
รูปร่างของเรื่องนี้สำคัญกว่าตัวกฎ สองในสามกฎที่โด่งดังของปี 2017 ไม่ได้มีหลักฐานใหม่ในปี 2025 มันคือหลักฐานชุดเดิมที่ถูกเลื่อนจากคำแนะนำเป็นข้อบังคับหลังใช้งานจริงแปดปี แปดปีนั้นไม่ได้ใช้หาหลักฐาน แต่ใช้รอให้หลักฐานชุดเดิมหนักพอจะเขียนเป็นคำสั่ง
สิ่งที่กรณีนี้สอน: ก่อนบังคับกฎกับผู้ใช้ ถามว่ากฎนั้นถูกวัดกับรหัสผ่านที่รั่วจริง หรือกับแบบจำลองความสุ่มบนกระดาษ
กุญแจฮาร์ดแวร์กับ MFA
ตัวเลขที่ใช้ขาย MFA และกุญแจฮาร์ดแวร์มาเกือบสิบปีมีอยู่สามตัว เรียงกันในสไลด์เดียวจนฟังดูเหมือนงานวิจัยสามชิ้น พอไล่กลับไปหาต้นทาง ตัวแรกเป็นคำให้สัมภาษณ์ ตัวที่สองเป็นสถิติภายในที่ไม่ได้ตีพิมพ์ ตัวที่สามไม่มีอยู่ในเอกสารของหน่วยงานที่ถูกอ้างชื่อ ไม่ได้แปลว่า MFA ไม่ได้ผล — ตัวเลขที่วัดจริงออกมาสูง แต่ช้ากว่าคำขวัญสี่ปี
วันที่ 23 กรกฎาคม 2018 โฆษกของ Google บอกนักข่าว Brian Krebs ว่าพนักงานกว่า 85,000 คนไม่มีใครถูก phishing ยึดบัญชีได้เลย นับตั้งแต่บริษัทบังคับใช้กุญแจฮาร์ดแวร์ต้นปี 2017 และมันคือคำให้สัมภาษณ์ ไม่ใช่งานวิจัย แหล่งหลักอีกแหล่งเป็นประโยคเดียวในบล็อกสินค้าของ Google Cloud วันที่ 30 สิงหาคม 2018 ตอนเปิดตัวกุญแจ Titan: ไม่มีรายงานหรือการยืนยันว่าบัญชีถูกยึด "จาก password phishing" นับตั้งแต่บังคับใช้กุญแจกับพนักงาน ไม่มีวิธีวัด ไม่มีตัวหาร ไม่มีผู้ตรวจสอบอิสระ และขอบเขตถูกจำกัดไว้ที่ password phishing เท่านั้น งานวิจัยจริงของ Google มีฉบับเดียว คือ Lang และคณะในการประชุม Financial Cryptography and Data Security ปี 2016 — มักถูกอ้างผิดว่าเป็น USENIX — รายงานการใช้งานสองปีภายในบริษัท เรื่องเวลาที่ใช้ยืนยันตัวและภาระฝ่ายสนับสนุน ไม่ได้อ้างว่า phishing เป็นศูนย์ ตัวเลขภายในของงานนั้นอ่านได้จากบทคัดย่อเท่านั้นในการค้นคว้าครั้งนี้ เล่มนี้จึงไม่พิมพ์
ตัวเลขที่สองคือ 99.9% ของ Microsoft ที่มาคือบล็อกของ Alex Weinert วันที่ 20 สิงหาคม 2019: บัญชีที่เปิด MFA มีโอกาสถูกยึด "น้อยลงกว่า 99.9%" คำนวณจากข้อมูลภายในที่เห็นความพยายามล็อกอินปลอมราว 300 ล้านครั้งต่อวัน ในปี 2019 และไม่เคยตีพิมพ์ สี่ปีต่อมาจึงมีคนวัดจริง Meyer และคณะจาก Microsoft Research (arXiv 2305.00945, 1 พฤษภาคม 2023) ตรวจบัญชี Azure AD ที่มีพฤติกรรมน่าสงสัย ด้วยวิธี benchmark-multiplier ร่วมกับตรวจบัญชีด้วยมือ ได้ผลว่า MFA ลดความเสี่ยงถูกยึดบัญชี 99.22% ทั้งประชากร และ 98.56% ในบัญชีที่รหัสผ่านรั่วไปแล้ว บัญชีที่เปิด MFA มากกว่า 99.99% ไม่ถูกยึดตลอดช่วงศึกษา แอปยืนยันตัวดีกว่า SMS และทั้งสองดีกว่าไม่มี MFA คำขวัญได้ออกวิ่งไปก่อนสี่ปี โดยไม่ต้องรอให้ใครอนุมัติวิธีวัดให้มัน
ตัวเลขที่สามตายในการค้นคว้า "CISA บอกว่า MFA กัน 99% ของการโจมตี" เอกสาร MFA ของ CISA ที่อ่านในการค้นคว้าครั้งนี้ — แผ่นข้อมูลเดือนมกราคม 2022 และแนวทางวันที่ 31 ตุลาคม 2022 — ไม่มีตัวเลข 99% อยู่เลย ตัวเลขนั้นเป็นของ Microsoft ที่ถูกย้ายชื่อเจ้าของ การย้ายชื่อทำให้สถิติภายในของบริษัทหนึ่ง กลายเป็นคำแนะนำของหน่วยงานรัฐโดยไม่มีใครวัดอะไรเพิ่ม สิ่งที่ CISA พูดจริงคือให้ใช้ MFA แบบทน phishing ได้ (FIDO/WebAuthn, PKI) และเตือนว่า MFA แบบกดยืนยันบนมือถือกับแบบ SMS ถูกหลอกผ่านได้
คำเตือนข้อหลังนั้นคือสันของเล่มในรูปย่อ ผู้โจมตีปรับตัวเข้าหา SMS และปุ่มกดยืนยันไปแล้ว กุญแจฮาร์ดแวร์คือแบบที่ออกแบบไว้รับการปรับตัวนั้น ส่วนตัวเลขของ Google ยังไม่มีงานวิจัยรองรับจนถึงวันนี้ — ของที่ใช้ได้จริง กับของที่พิสูจน์แล้ว ไม่ใช่ของสิ่งเดียวกัน
สิ่งที่กรณีนี้สอน: เมื่อได้ยินตัวเลขผลของการป้องกัน ให้ถามหาเอกสารที่มีตัวหารและวิธีวัด — คำพูดโฆษกไม่มีทั้งสองอย่าง
HTTPS ทั้งเว็บ · 2015–
ปี 2015 ใครก็ตามที่นั่งอยู่บนเส้นทางระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ ยังอ่านหน้าเว็บส่วนใหญ่ที่วิ่งผ่านหน้าเขาได้ตามสบาย หน้าเว็บที่ Firefox โหลดผ่าน HTTPS ในช่วงนั้นยังต่ำกว่า 30% ของทั้งหมด สิ่งที่ทำให้กรณีนี้อยู่ในภาคนี้ไม่ใช่ว่าตัวเลขนั้นขยับไปได้เท่าไร แต่เป็นว่ามีคนวัดเส้นนั้นทุกวันตลอดสิบปี ด้วยเครื่องมือที่ระบุชื่อได้
วันที่ 14 กันยายน 2015 Let's Encrypt ออกใบรับรองที่เบราว์เซอร์เชื่อถือใบแรกให้ helloworld.letsencrypt.org โครงการประกาศตัวก่อนหน้านั้นวันที่ 18 พฤศจิกายน 2014 ผู้สนับสนุนก่อตั้งคือ Mozilla, EFF, Cisco, Akamai และ IdenTrust ลายเซ็นไขว้ของ IdenTrust คือสิ่งที่ทำให้ใบรับรองใบแรกได้รับความเชื่อถือ เพราะใบรับรองที่ไม่มีใครที่เบราว์เซอร์รู้จักอยู่แล้วรับรองให้ ก็เป็นแค่ไฟล์ จากนั้นเปิดเบต้าสาธารณะ 3 ธันวาคม 2015 ใบที่หนึ่งล้านออกเดือนมีนาคม 2016 ใบที่หนึ่งร้อยล้านเดือนมิถุนายน 2017 ถึงหนึ่งล้านใบต่อวันเดือนกันยายน 2018 ใบที่หนึ่งพันล้านเดือนกุมภาพันธ์ 2020 และปลายเดือนกันยายน 2025 ออกได้สิบล้านใบในวันเดียว
แต่จำนวนใบไม่ใช่เป้าหมาย ISRG ผู้ดำเนินโครงการเขียนไว้เองในบทความครบสิบปีวันที่ 9 ธันวาคม 2025 ว่าสิ่งที่วัดคือสัดส่วนหน้าเว็บที่โหลดผ่าน HTTPS จาก Firefox Telemetry ค่าเฉลี่ยเคลื่อนที่ 14 วัน ตัวเลขในคำของ Josh Aas: ใช้เวลาราวห้าปีดันสัดส่วนทั่วโลกจากต่ำกว่า 30% ไปถึงราว 80% แล้วนิ่งอยู่ตรงนั้นตั้งแต่นั้นมา ในสหรัฐอยู่ใกล้ 95% มาระยะหนึ่งแล้ว ตัวเลขรายปีพร้อมวันที่ไม่ได้มาจากแหล่งต้นทางในการค้นคว้าครั้งนี้ หน้าสถิติของ Let's Encrypt วาดกราฟด้วย JavaScript และรายงานของ Google หยุดที่ข้อมูลเดือนกรกฎาคม 2022 เล่มนี้จึงพิมพ์เฉพาะตัวเลขที่ ISRG เขียนเอง
ต้องพูดให้ชัดว่าเส้นกราฟเส้นนี้วัดอะไร HTTPS เป็นการป้องกันที่วัดการใช้ ไม่ได้วัดการโจมตีที่ถูกกัน สัดส่วน 80% บอกว่าสายส่งถูกเข้ารหัสไปแค่ไหน มันไม่ได้บอกว่าผู้ดักฟังที่เคยอ่านสายส่งย้ายไปทำอะไรต่อ ข้อดีของมันอยู่ที่อย่างอื่น คือมันเป็นการป้องกันที่มีเส้นกราฟก่อน-หลังยาวสิบปี จากเครื่องวัดที่ระบุชื่อได้ ซึ่งเป็นของที่การป้องกันส่วนใหญ่ในภาคนี้ไม่มี
และของที่หายากกว่าพื้นคือเพดาน 20% สุดท้ายไม่ขยับมาห้าปี ISRG บอกตรงๆ ว่าไม่รู้ว่ามันคืออะไร เดาว่าเป็นเครือข่ายภายในองค์กรและเว็บส่วนตัว แล้วเรียกมันว่าคำถามวิจัยที่ยังเปิดอยู่ องค์กรที่ดันตัวเลขของตัวเองขึ้นไปได้ห้าสิบจุดแล้วเขียนว่าไม่รู้ว่าอะไรขวางอยู่ กำลังทำสิ่งที่คนขายของไม่ทำ การป้องกันที่ผู้ดำเนินการวัดเพดานของตัวเองแล้วพิมพ์ออกมา มีค่ากว่าการป้องกันที่วัดได้แค่พื้น
สิ่งที่กรณีนี้สอน: ถามว่าตัวชี้วัดของการป้องกันวัดการใช้หรือวัดผล แล้วถามต่อว่าเพดานของมันอยู่ตรงไหน และใครรู้ว่าทำไม
ภาษาที่ปลอดภัยกับหน่วยความจำ · 2019–2024
ช่องโหว่ประเภท memory safety ถูกปฏิบัติมาตลอดเหมือนสภาพอากาศ คือเรื่องที่ต้องวางแผนอยู่กับมัน ไม่ใช่เรื่องที่จะทำให้หมดไป ทุกคนรู้ว่ามันคือสัดส่วนใหญ่ที่สุดของบั๊กด้านความปลอดภัย ทุกคนรู้วิธีลดมันทีละตัว และไม่มีใครมีกราฟที่แสดงว่ามันเล็กลงทั้งประเภท
วันที่ 25 กันยายน 2024 Google รายงานจากข้อมูล security bulletin ของตัวเองว่าช่องโหว่ประเภท memory safety เคยเป็น 76% ของช่องโหว่ทั้งหมดใน Android ปี 2019 และในปี 2024 เหลือ 24% ต่ำกว่าค่ากลางของอุตสาหกรรมที่ 70% และยังลดต่อ สิ่งที่หายากในเรื่องนี้ไม่ใช่ตัวเลข แต่เป็นรูปร่างของมัน — บั๊กทั้งประเภทหนึ่งค่อยๆ ตายลงบนกราฟ ในสาขาที่คุ้นกับการเห็นเส้นแบนมาตลอด
ส่วนที่ขัดกับสามัญสำนึกคือ Android ไม่ได้เขียนโค้ด C/C++ เก่าใหม่ ตั้งแต่ราวปี 2019 งานพัฒนาใหม่ย้ายไปภาษาที่ปลอดภัยกับหน่วยความจำ โค้ดเก่าถูกปล่อยไว้ แก้เฉพาะตอนมีบั๊ก และจำนวนจริงลดด้วย ไม่ใช่แค่สัดส่วน ปี 2024 ประมาณการไว้ที่ 36 CVE ประเภทนี้ทั้งปี นับได้ 27 ถึง bulletin เดือนกันยายน
กลไกที่ Google เสนออธิบายว่าทำไมการไม่แตะโค้ดเก่าถึงได้ผล ช่องโหว่สลายตัวตามอายุโค้ด โค้ดอายุห้าปีมีความหนาแน่นของช่องโหว่ต่ำกว่าโค้ดใหม่ 3.4 เท่า (จากงานภายนอก) ถึง 7.4 เท่า (จากที่สังเกตใน Android และ Chromium) หลักฐานที่อ้างคือ Alexopoulos และคณะ USENIX Security 2022 เรื่องอายุขัยของช่องโหว่ในโค้ด เมื่อของใหม่ไม่ไหลเข้า สต็อกเก่าก็เสื่อมไปเอง หยุดกระแสเข้าจึงชนะการล้างสต็อก และมันชนะโดยไม่ต้องขอ budget ไปเขียนของที่ใช้งานได้อยู่แล้วใหม่ทั้งกอง ตัวเลขข้างเคียงสองตัว: อัตรา rollback ของการเปลี่ยนแปลงที่เขียนด้วย Rust ต่ำกว่าของ C++ ไม่ถึงครึ่ง และตัวสร้าง QR ของ Chromium ที่เขียนด้วย Rust เร็วขึ้น 20 เท่าเมื่อถอด sandbox ที่ไม่จำเป็นแล้วออก ความปลอดภัยซื้อประสิทธิภาพที่มาตรการรุ่นก่อนเคยกินไปคืนมา
ค่า 70% ของอุตสาหกรรมต้องติดดาวไว้ มันมาจาก Matt Miller แห่ง MSRC ในงาน BlueHat IL เดือนกุมภาพันธ์ 2019: ราว 70% ของ CVE ที่ Microsoft แก้ในแต่ละปี ตลอดราวสิบสองปีก่อนหน้า เป็นปัญหา memory safety ตัวเลขนี้กับค่ากลางที่ Google อ้างไม่ใช่สองแหล่งอิสระ มันคือสมอตัวเดียวกัน วันที่ 6 ธันวาคม 2023 CISA, NSA, FBI และหน่วยงานพันธมิตรตีพิมพ์ The Case for Memory Safe Roadmaps ภายใต้โครงการ Secure by Design
ความเชื่อที่ตายในการค้นคว้า: "Android แก้ memory safety ด้วยการเขียน C++ ใหม่เป็น Rust" Google เขียนไว้ตรงข้าม โค้ดเก่าแทบไม่ถูกแตะ ที่ย้ายคือโค้ดใหม่เท่านั้น ในแง่สันของเล่ม นี่คือการป้องกันที่ไม่ได้เพิ่มด่านให้ผู้โจมตีเดินอ้อม แต่เอาชั้นของบั๊กออกจากโค้ดที่เขียนหลังจากนั้น ผู้โจมตีปรับตัวหาช่องโหว่ที่ไม่มีอยู่ไม่ได้
สิ่งที่กรณีนี้สอน: ปิดทางเข้าของบั๊กประเภทหนึ่งในโค้ดใหม่ก่อนคิดเขียนโค้ดเก่าใหม่ แล้ววัดด้วยสัดส่วนของช่องโหว่รายปี ไม่ใช่จำนวนบรรทัดที่ย้าย
หลักแปดข้อของ Saltzer และ Schroeder · 1975
หลักออกแบบความปลอดภัยแปดข้อที่หลักสูตรทุกหลักสูตรสอน และที่องค์กรเขียนไว้ในนโยบายว่ายึดถือ มาจากบทความเดียวเมื่อห้าสิบปีก่อน เดือนกันยายน 1975 J. H. Saltzer และ M. D. Schroeder ตีพิมพ์มันใน Proceedings of the IEEE ฉบับที่ 63 เล่มที่ 9 ด้วยประโยคเปิดว่าไม่มีใครรู้วิธีสร้างระบบที่ไม่มีข้อบกพร่อง ทางเลือกจึงเป็นหลักที่ทำให้ข้อบกพร่องน้อยลงและเบาลง ห้าสิบปีต่อมา คำถามที่ตอบได้คือข้อไหนถูกสร้างจริง และคำตอบมีรูปร่างชัดเจนมาก ข้อที่ถูกใช้คือข้อที่เพิ่มการควบคุม ข้อที่ถูกทิ้งคือข้อที่บังคับให้สละบางอย่าง
แปดข้อในคำของพวกเขาเอง: economy of mechanism — ออกแบบให้เล็กและง่ายที่สุด fail-safe defaults — ตัดสินสิทธิ์จากการอนุญาต ไม่ใช่จากการยกเว้น complete mediation — ทุกการเข้าถึงทุกวัตถุต้องถูกตรวจสิทธิ์ open design — แบบต้องไม่เป็นความลับ separation of privilege — กลไกที่ต้องใช้สองกุญแจแข็งแรงกว่ากุญแจเดียว least privilege — ทุกโปรแกรมและทุกผู้ใช้ทำงานด้วยสิทธิ์น้อยที่สุดที่งานต้องการ least common mechanism — ลดกลไกที่ผู้ใช้หลายคนใช้ร่วมกัน และ psychological acceptability — ส่วนติดต่อผู้ใช้ต้องง่ายพอให้คนใช้การป้องกันถูกต้องโดยอัตโนมัติ
สิ่งที่มักหายไปตอนถูกอ้างคืออีกสองข้อที่ผู้เขียนระบุเองว่าใช้กับคอมพิวเตอร์ได้ไม่เต็มที่ ข้อแรก work factor — เทียบต้นทุนที่ต้องใช้เจาะกลไกกับทรัพยากรของผู้โจมตี ข้อโต้แย้งของพวกเขาเอง: กลไกป้องกันในคอมพิวเตอร์ส่วนใหญ่คำนวณ work factor ตรงๆ ไม่ได้ เพราะมันถูกเจาะด้วยทางอ้อม รอฮาร์ดแวร์เสีย หรือหาข้อผิดพลาดในโค้ด และไม่มีใครประมาณเวลาของทางอ้อมได้ นี่คือประโยคปี 1975 จากคนเขียนหลักการเอง ว่าความมั่นคงปลอดภัยของระบบวัดแบบ cryptanalysis ไม่ได้ — เขียนไว้ก่อนอุตสาหกรรมที่ขายคะแนนความเสี่ยงเป็นตัวเลขเดียวจะเกิดขึ้นหลายสิบปี ข้อสอง compromise recording — บันทึกให้ได้ว่าถูกเจาะ แทนที่จะกัน ข้อโต้แย้ง: ผู้โจมตีที่ฉลาดพอลบบันทึกนั้นได้ด้วย อุตสาหกรรม audit log และ SIEM ยืนอยู่บนหลักที่ผู้เขียนตัดออก
ห้าสิบปีผ่านไป ข้อไหนถูกใช้จริง — ต่อไปนี้เป็นการประเมิน ไม่ใช่การวัด least privilege ถูกใช้โดยเรียกชื่อตรงๆ ใน IAM, sandbox, container และ sudo fail-safe defaults กลายเป็น firewall แบบปฏิเสธก่อน open design ถูกใช้ในวิทยาการเข้ารหัสสาธารณะ complete mediation ถูกยอมรับในหลักการและถูกละเมิดเพื่อความเร็ว — cache ผลตรวจสิทธิ์และบั๊ก TOCTOU คือรูปที่ผู้เขียนทำนาย separation of privilege ได้ครึ่งเดียว ในรูป MFA และกฎสองคน
สองข้อถูกทิ้ง economy of mechanism — ระบบสมัยใหม่คือขั้วตรงข้ามของเล็กและง่าย และ least common mechanism — cloud ที่ผู้เช่าหลายรายใช้ร่วม kernel ร่วม cache ของ CPU ร่วม Spectre, Meltdown และ Rowhammer คือการละเมิดข้อนี้โดยมีซิลิคอนรองอยู่ข้างใต้ ทั้งสองข้อไม่ได้ถูกทิ้งเพราะไม่รู้ แต่เพราะราคา ข้อหนึ่งขอให้เลิกใส่ฟีเจอร์ อีกข้อขอให้เลิกแบ่งเครื่องกันใช้ และไม่มีใครอยากจ่ายทั้งสองอย่าง
สิ่งที่กรณีนี้สอน: ในรายการหลักการที่องค์กรอ้างว่ายึดถือ ขีดเส้นใต้ข้อที่บังคับให้เลิกทำบางอย่าง — ข้อนั้นคือข้อที่ยังไม่ได้ทำ
การเปิดเผยช่องโหว่แบบประสานงาน
คนที่พบช่องโหว่กับคนที่ต้องแก้มันไม่เคยอยู่ภายใต้เส้นตายเดียวกัน ผู้ขายเป็นคนกำหนดว่าจะแก้เมื่อไร ส่วนคนที่รายงานเข้าไปมีทางเลือกอยู่สองทาง คือรอ หรือเปิดเผยเองแล้วรับผลที่ตามมา สิ่งที่ CERT/CC ทำในปี 2000 คือเอานาฬิกามาวางไว้ตรงกลาง
วันที่ 9 ตุลาคม 2000 นโยบายของ CERT/CC มีผลบังคับ: ช่องโหว่ที่รายงานเข้ามาจะถูกเปิดเผยต่อสาธารณะหลัง 45 วันนับจากรายงานครั้งแรก ไม่ว่าจะมีแพตช์หรือไม่ Shawn Hernan หัวหน้าทีมจัดการช่องโหว่ของ CERT/CC ประกาศบน BugTraq วันที่ 4 ตุลาคม 2000 ข้อยกเว้นมีสามแบบ ถูกโจมตีจริงอยู่แล้ว ภัยร้ายแรงเป็นพิเศษหรือเบาเป็นพิเศษ และช่องโหว่ที่ต้องแก้มาตรฐานที่ใช้อยู่
จุดสำคัญของแบบนี้คือนาฬิกาไม่ขึ้นกับแพตช์ มันไม่ใช่คำสัญญาต่อผู้ขาย มันคือเส้นตายที่บังคับผู้ขาย และนั่นคือสิ่งที่ทำให้มันใช้ประสานงานได้จริง นาฬิกา 45 วันยังเป็นนโยบายที่ CERT/CC พิมพ์อยู่จนวันนี้ และเป็นจุดอ้างอิงที่กรอบเวลาอื่นวัดตัวเองเทียบ — Project Zero ของ Google ใช้ 90 วัน ZDI ใช้ 120 วัน
ขนาดของตลาดที่ตามมาวัดได้ HackerOne จ่ายค่าตอบแทนสะสมเกิน 300 ล้านดอลลาร์ ณ เดือนตุลาคม 2023 ตามแถลงของบริษัทเอง Google จ่ายผ่านโครงการ VRP 11.8 ล้านดอลลาร์ให้ผู้วิจัย 660 คนในปี 2024 ตัวเลขนี้อ่านจากรายงานข่าวที่อ้างบล็อกของ Google ไม่ใช่จากบล็อกโดยตรง
แล้วมันลดเหตุการณ์ได้ไหม คำตอบตรงคือยังไม่มีใครแสดง สิ่งที่วรรณกรรมวัดคืออัตราการค้นพบและต้นทุนต่อบั๊ก ซึ่งเป็นคนละเรื่องกัน Finifter, Akhawe และ Wagner ใน USENIX Security 2013 คำนวณว่าโครงการของ Chrome มีต้นทุนราว 485 ดอลลาร์ต่อวัน ของ Mozilla ราว 658 ดอลลาร์ต่อวัน และโครงการหนึ่งได้รายงานที่ใช้ได้ราว 0.429 ฉบับต่อวัน หรือราว 156 ต่อปี ข้อสรุปของพวกเขาเป็นเรื่องเศรษฐศาสตร์ล้วนๆ คือถูกกว่าจ้างนักวิจัยเต็มเวลาจำนวนเท่ากัน ไม่ใช่ข้อสรุปเรื่องเหตุการณ์ที่เลี่ยงได้ Walshe และ Simpson จาก Oxford ปี 2020 ได้ทิศทางเดียวกัน ต้นทุนรายปีของโครงการต่ำกว่าจ้างวิศวกรเพิ่มสองคน และความสำเร็จของโครงการสัมพันธ์กับค่าตอบแทนเฉลี่ยเพียงอ่อนๆ ส่วนงานศึกษา Chromium และ Firefox ใน ACM Web Conference 2023 บอกว่าทำไมมันถึงแทนกันไม่ได้ บั๊กที่นักล่าภายนอกเจอต่างจากที่ทีมภายในเจอ และต่างจากที่ผู้โจมตีเจอ bug bounty จึงเสริมการตรวจภายใน ไม่ได้แทน
ข้อความที่ป้องกันได้จึงเป็นแบบนี้ bug bounty เป็นช่องทางค้นพบที่ถูกและวัดได้ดี ส่วนข้อความว่ามันลดการเจาะระบบ ไม่มีค่าประมาณเชิงสาเหตุตีพิมพ์ในทางใดทางหนึ่ง มันเป็นคำถามที่ยังเปิด ไม่ใช่คำตอบว่าไม่ ในแง่สันของเล่ม นาฬิกา 45 วันคือการป้องกันที่ออกแบบจากข้อเท็จจริงว่าผู้โจมตีปรับตัว มันแข่งกับเขา ไม่ได้รอผู้ขาย
สิ่งที่กรณีนี้สอน: แยกตัวเลขที่วัดการค้นพบออกจากตัวเลขที่วัดเหตุการณ์ ก่อนใช้ตัวแรกจ่ายเงินซื้อตัวหลัง
fuzzing · 2016–
วิธีหาช่องโหว่ที่ผู้โจมตีใช้ได้เสมอคือยิงอินพุตสุ่มใส่โค้ดจนมันพัง fuzzing คือฝ่ายป้องกันทำสิ่งเดียวกันนั้น แต่ทำก่อน และในกรณีนี้ทำฟรีให้โครงการที่ไม่มีเงินจ้างใครมาทำ แรงจูงใจที่ประกาศไว้คือ Heartbleed — บั๊กในโค้ดที่คนอื่นใช้ต่อกันทั้งอินเทอร์เน็ต และไม่มีใครเป็นเจ้าของงบประมาณสำหรับตรวจมัน
วันที่ 1 ธันวาคม 2016 Google เปิดตัว OSS-Fuzz และถึงเดือนพฤษภาคม 2025 README ของโครงการนับช่องโหว่ที่เจอได้เกิน 13,000 รายการ บั๊กรวมเกิน 50,000 รายการ ในโครงการโอเพนซอร์ส 1,000 โครงการ โครงการเดินร่วมกับ Core Infrastructure Initiative และต่อมา OpenSSF เครื่องมือคือ libFuzzer, AFL++ และ Honggfuzz ทำงานคู่กับ sanitizer และ ClusterFuzz ที่กระจายงานไปหลายเครื่อง ภาษาที่รับคือ C/C++, Rust, Go, Python, Java, JavaScript และ Lua
เส้นทางของตัวเลขบอกอัตราการเติบโต เดือนสิงหาคม 2023 บล็อกของ Google รายงานช่องโหว่เกิน 10,000 และบั๊กเกิน 36,000 ในราว 1,000 โครงการ เดือนพฤศจิกายน 2024 fuzz target ที่ AI สร้างเพิ่มโค้ดที่ถูกทดสอบกว่า 370,000 บรรทัดใน 272 โครงการ C/C++ ปัจจุบัน OSS-Fuzz ทดสอบให้เกิน 1,300 โครงการโดยผู้ดูแลไม่ต้องจ่าย ตัวเลข "40,500 บั๊กใน 650 โครงการ" จากเดือนกรกฎาคม 2022 ที่แพร่อยู่ ขัดกับตัวเลข 36,000 ของปีถัดมา วิธีนับเปลี่ยนตรงไหนไม่ทราบ เล่มนี้ใช้ตัวเลขใน README ที่ Google ยืนยันเองในปัจจุบัน
น้ำหนักถ่วงมาจาก Google เอง และนี่คือส่วนที่ทำให้กรณีนี้ต่างจากการป้องกันอื่น บทความเรื่อง memory safety ของ Android วันที่ 25 กันยายน 2024 จัด fuzzing เป็นมาตรการรุ่นที่สาม "ค้นหาช่องโหว่เชิงรุก" และเขียนว่าวิธีแบบนี้แก้อาการของ memory unsafety ไม่ใช่ต้นเหตุ มันต้องกดดันทีมตลอดเวลาให้ fuzz คัดกรอง และแก้สิ่งที่เจอ ผลที่ตามมาคือความครอบคลุมต่ำ และแม้ทำอย่างทั่วถึง fuzzing ก็ไม่ให้ความมั่นใจสูง — หลักฐานคือช่องโหว่ที่ยังเจอในโค้ดที่ถูก fuzz มาแล้วมาก คาดการณ์ของ Google คือจะพึ่ง fuzzing น้อยลงเมื่อโค้ดที่ปลอดภัยกับหน่วยความจำแพร่ออกไป และได้ผลสูงขึ้นบนพื้นผิวที่เล็กลง
ตัวเลข 13,000 จึงต้องอ่านให้ถูก มันวัดสิ่งที่เจอ ไม่ได้วัดสิ่งที่เหลือ และคนที่เตือนเรื่องนี้ดังที่สุดคือผู้ดำเนินการเอง การป้องกันที่เจ้าของพิมพ์เพดานของตัวเองออกมาเป็นของหายากพอที่จะนับได้
สิ่งที่กรณีนี้สอน: อ่านหาเพดานที่ผู้สร้างเครื่องมือประกาศเอง ก่อนอ่านจำนวนบั๊กที่มันจับได้
การป้องกันที่ไม่มีหลักฐานรองรับ
ไม่มีใครซื้อการอบรม security awareness เพราะความงมงาย คนที่เซ็นใบสั่งซื้อมีหลักฐานอยู่ในมือจริงๆ สิ่งที่ผิดจึงไม่ใช่การตัดสินใจ แต่เป็นตัวเลขที่หลักฐานชุดนั้นวัด
ปี 2025 การทดลองแบบสุ่มควบคุมนาน 8 เดือนกับพนักงานกว่า 19,500 คนของ UC San Diego Health พบว่าการอบรม security awareness ประจำปี ไม่มีความสัมพันธ์กับโอกาสที่พนักงานจะตกเป็นเหยื่อ phishing จำลอง Ho และคณะตีพิมพ์ใน IEEE Symposium on Security and Privacy 2025 ส่ง phishing จำลอง 10 รอบ และเป็นหนึ่งในสองงานเท่านั้นที่สุ่มจัดกลุ่มว่าใครได้อบรม ผลข้อแรก คนที่เพิ่งอบรมเสร็จเมื่อวานกับคนที่อบรมมาสิบเอ็ดเดือนก่อน คลิกพอกัน ผลข้อสอง บทเรียนที่เด้งขึ้นทันทีเมื่อคลิกผิด ลดอัตราพลาดได้ 1.7% เทียบกับกลุ่มควบคุม ผลข้อสาม เหยื่อล่อธรรมดาดึงคนได้ 1–2% เหยื่อล่อที่ทำดีดึงได้เกิน 30% ตัวเลข 1.7% อ่านจากบทคัดย่อและแถลงของ UCSD ไม่ใช่จากตัวบทความ
ตัวเลขที่ฆ่าการป้องกันนี้ไม่ใช่ 1.7% แต่เป็นอัตราส่วนของสองผลหลัง ตัวแปรที่ฝ่ายป้องกันคุมได้ — การอบรม — ขยับผลราว 2 จุด ตัวแปรที่ผู้โจมตีคุมได้ — คุณภาพเหยื่อล่อ — ขยับราว 29 จุด ศัตรูถือตัวแปรที่แรงกว่าราวสิบห้าเท่า ต่อให้ฝ่ายป้องกันดันตัวแปรของตัวเองจนสุดทาง อีกฝั่งก็ยังกว้างกว่า ETH Zurich ได้ผลทางเดียวกันก่อนหน้านั้น Lain และคณะใน IEEE S&P 2022 ตามพนักงานกว่า 14,000 คนนาน 15 เดือน พบว่าการอบรมแบบฝังในเหตุการณ์ไม่ได้ผล และในบางเงื่อนไขทำให้แย่ลง — คนที่ได้บทเรียนหลังคลิกพลาด คลิกในรอบถัดไปมากกว่า
แล้วข้อความว่า "การอบรมได้ผล" มาจากไหน จากงานทบทวน 69 การศึกษาใน Computers & Security ปี 2024 ที่รายงานผลรวมแรง แต่งานส่วนใหญ่ในนั้นวัดความรู้และความตั้งใจ ไม่ได้วัดการคลิก และบ่อยครั้งไม่มีกลุ่มควบคุม สองงานใหญ่ที่มีกลุ่มควบคุมและวัดพฤติกรรม ได้ผลใกล้ศูนย์ทั้งคู่ ส่วนตัวเลขลดคลิกได้ถึง 86% ที่ผู้ขายพิมพ์ เป็นตัวเลขก่อน-หลังที่ไม่มีกลุ่มควบคุม จากคนที่ขายการอบรมเอง
ของชิ้นที่สองคือ antivirus แบบลายเซ็น และมันซ้ำรูปเดิม การประเมิน AI ATAC 1 ของ Oak Ridge National Laboratory ที่กองทัพเรือสหรัฐให้ทุน (arXiv 2308.14835, สิงหาคม 2023) ทดสอบเครื่องมือตรวจจับเชิงพาณิชย์กับไฟล์ 100,000 ไฟล์ ครึ่งดีครึ่งร้าย ในนั้นมีไฟล์รันได้ที่ไม่เคยมีใครเห็น (zero-day) ราว 1,000 ไฟล์ เครื่องมือแบบลายเซ็นจับ zero-day ได้ราว 4% แบบ machine learning ได้ราว 40% หนึ่งในยี่สิบห้ากับสองในห้า ไม่มีตัวไหนใกล้โฆษณา Botacin และคณะใน Computers & Security ปี 2020 ส่งมัลแวร์ที่เพิ่งเก็บใหม่ 28,875 ตัวอย่างขึ้น VirusTotal ติดต่อกัน 30 วัน และพบว่าการประเมิน antivirus เกือบทั้งหมดลดเหลือตัวเลขเดียวคืออัตราตรวจจับ ไม่วัดเวลากว่าจะจับได้ ไม่วัดตัวอย่างที่เคยจับได้แล้วกลับหลุด
คนที่ซื้อของสองอย่างนี้มีเหตุผลรองรับ การอบรมมีงานทบทวน 69 ชิ้นหนุน antivirus มีอัตราตรวจจับที่ผู้ขายพิมพ์ให้ดู สิ่งที่ผิดคือตัวเลขที่วัดผิดตัว — วัดความตั้งใจแทนการคลิก วัดมัลแวร์เก่าแทนมัลแวร์ใหม่ ทั้งสองกรณี ตัวที่ไม่ได้วัดคือตัวที่ผู้โจมตีถือ
สิ่งที่กรณีนี้สอน: ก่อนต่ออายุการป้องกันใดๆ ขอตัวเลขก่อน-หลังที่มีกลุ่มควบคุม จากคนที่ไม่ได้ขายมัน แล้วถามว่าตัวเลขนั้นวัดพฤติกรรมหรือวัดความตั้งใจ
ท่าที่เอาไปใช้ได้: เขียนรายการการป้องกันที่องค์กรจ่ายเงินซื้ออยู่ แล้วใส่ตัวเลขก่อน-หลังที่มีกลุ่มควบคุมจากคนที่ไม่ได้ขายมันไว้ข้างแต่ละรายการ ช่องที่ว่างไม่ได้แปลว่าใช้ไม่ได้ มันแปลว่ายังไม่มีใครวัด และงบก้อนถัดไปควรไปที่การวัดก่อนซื้อเพิ่ม
จะพลิกคำตัดสินของภาคนี้ได้เมื่อ: มีการทดลองแบบสุ่มควบคุมขนาดใกล้เคียง 19,500 คน ที่พบว่า training ลดอัตราคลิกได้มากกว่าที่คุณภาพเหยื่อล่อขยับ หรือมีการประเมินอิสระขนาด 100,000 ไฟล์ที่ signature detection จับไฟล์รันได้ที่ไม่เคยเห็นมาก่อนได้เกินครึ่ง หรือ security bulletin ของ Android รายงานสัดส่วน memory safety กลับขึ้นเหนือ 50% โดยวิธีนับไม่เปลี่ยน
แหล่งของภาคนี้:
- NIST SP 800-63B (2017) มาตรา 5.1.1 — https://pages.nist.gov/800-63-3/sp800-63b.html
- NIST SP 800-63B-4 (2025) — https://pages.nist.gov/800-63-4/sp800-63b.html
- ประวัติการตีพิมพ์ SP 800-63B-4: ร่างแรก 16 ธ.ค. 2022, ร่างสอง 21 ส.ค. 2024, ฉบับจริง 31 ก.ค. 2025 — https://csrc.nist.gov/pubs/sp/800/63/b/4/final
- Google Cloud blog เปิดตัว Titan key, 30 สิงหาคม 2018 — https://cloud.google.com/blog/products/identity-security/titan-security-keys-now-available-on-the-google-store
- Krebs on Security, 23 กรกฎาคม 2018 — https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/
- Lang และคณะ, Security Keys, FC 2016 — https://research.google.com/pubs/archive/45409.pdf
- Weinert, Microsoft Security blog, 20 สิงหาคม 2019 — https://www.microsoft.com/en-us/security/blog/2019/08/20/one-simple-action-you-can-take-to-prevent-99-9-percent-of-account-attacks/
- Meyer และคณะ, How effective is multifactor authentication at deterring cyberattacks?, 1 พฤษภาคม 2023 — https://arxiv.org/abs/2305.00945
- CISA, Multi-Factor Authentication Fact Sheet, มกราคม 2022 — https://www.cisa.gov/sites/default/files/publications/MFA-Fact-Sheet-Jan22-508.pdf
- CISA, Implementing Phishing-Resistant MFA — https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf
- Let's Encrypt ครบสิบปี, 9 ธันวาคม 2025 — https://letsencrypt.org/2025/12/09/10-years
- Let's Encrypt สถิติ (Firefox Telemetry) — https://letsencrypt.org/stats/
- Aas และคณะ, Let's Encrypt, ACM CCS 2019 — https://jhalderm.com/pub/papers/letsencrypt-ccs19.pdf
- Google Security Blog, memory safety ใน Android, 25 กันยายน 2024 — https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html
- Alexopoulos และคณะ, How Long Do Vulnerabilities Live in the Code?, USENIX Security 2022 — https://www.usenix.org/conference/usenixsecurity22/presentation/alexopoulos
- MSRC, A proactive approach to more secure code, กรกฎาคม 2019 — https://msrc.microsoft.com/blog/2019/07/a-proactive-approach-to-more-secure-code/
- CISA และพันธมิตร, The Case for Memory Safe Roadmaps, 6 ธันวาคม 2023 — https://www.cisa.gov/sites/default/files/2023-12/The-Case-for-Memory-Safe-Roadmaps-508c.pdf
- Saltzer และ Schroeder, The Protection of Information in Computer Systems, 1975 — https://www.cs.virginia.edu/~evans/cs551/saltzer/
- นโยบายเปิดเผยช่องโหว่ของ CERT/CC — https://certcc.github.io/certcc_disclosure_policy/
- Finifter, Akhawe และ Wagner, USENIX Security 2013 — https://dl.acm.org/doi/10.5555/2534766.2534790
- Walshe และ Simpson, IEEE 2020 — https://ieeexplore.ieee.org/document/9034828/
- กรณีศึกษา Chromium และ Firefox, ACM Web Conference 2023 — https://dl.acm.org/doi/10.1145/3543507.3583352
- HackerOne แถลงยอดสะสม 300 ล้านดอลลาร์, ตุลาคม 2023 — https://www.hackerone.com/press-release/hackers-surpass-300-million-all-time-earnings-hackerone-platform
- Google VRP ปี 2024 ตามรายงานข่าว — https://www.securityweek.com/google-paid-out-12-million-via-bug-bounty-programs-in-2024/
- OSS-Fuzz README, ตัวเลขถึงพฤษภาคม 2025 — https://github.com/google/oss-fuzz
- ประกาศ OSS-Fuzz, 1 ธันวาคม 2016 — https://opensource.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html
- Google, AI-Powered Fuzzing, สิงหาคม 2023 — https://security.googleblog.com/2023/08/ai-powered-fuzzing-breaking-bug-hunting.html
- Google, Leveling Up Fuzzing, พฤศจิกายน 2024 — https://security.googleblog.com/2024/11/leveling-up-fuzzing-finding-more.html
- Ho และคณะ, Understanding the Efficacy of Phishing Training in Practice, IEEE S&P 2025 — https://people.cs.uchicago.edu/~grantho/papers/oakland2025_phishing-training.pdf
- แถลงของ UC San Diego — https://today.ucsd.edu/story/cybersecurity-training-programs-dont-prevent-employees-from-falling-for-phishing-scams
- Lain และคณะ, Phishing in Organizations, IEEE S&P 2022 — https://arxiv.org/abs/2112.07498
- งานทบทวน 69 การศึกษา, Computers & Security 2024 — https://www.sciencedirect.com/science/article/pii/S016740482400511X
- AI ATAC 1, ORNL, สิงหาคม 2023 — https://arxiv.org/abs/2308.14835
- Botacin และคณะ, We need to talk about antiviruses, Computers & Security 2020 — https://www.sciencedirect.com/science/article/abs/pii/S0167404820301310