หกแนวคิดโง่ ๆ ในความปลอดภัยคอมพิวเตอร์ (2005)

 (ranum.com)
5 คะแนน โดย GN⁺ 2024-07-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ความปลอดภัยคอมพิวเตอร์เป็นสาขาที่มีผลิตภัณฑ์ งานประชุม หนังสือ และร่างกฎหมายเพิ่มขึ้นเรื่อย ๆ แต่รากของความล้มเหลวที่เกิดซ้ำอยู่ที่สมมติฐานพื้นฐานที่ผิด เช่น Default Permit และ Enumerating Badness
  • ปัญหาหลักคือโครงสร้างที่ไม่กำหนด “สิ่งที่จะอนุญาต” ให้แคบลง แต่ไล่ตาม “สิ่งที่จะบล็อก” อย่างไม่รู้จบ และหากไม่เลือก Default Deny ในไฟร์วอลล์ การรันโค้ด และการรับมือเวิร์ม ก็จะตกสู่การแข่งขันสะสมอาวุธกับผู้โจมตี
  • การทำรายการสิ่งไม่ดีคือวิธีติดตามไวรัสมากกว่า 75,000 ตัวและภัยคุกคามใหม่ 200–700 รายการต่อเดือน จึงไม่มีประสิทธิภาพเท่ากับ Enumerating Goodness ซึ่งบริหารจัดการแอปพลิเคชันปกติราว 30 รายการที่จำเป็นจริง ๆ
  • วิธีค้นหาช่องโหว่แล้วแพตช์ วัฒนธรรมที่บริโภคการแฮ็กอย่างเท่ และกลยุทธ์ที่พึ่งพาการให้ความรู้ผู้ใช้ ล้วนทำให้ต้องทำ การตอบสนองหลังเกิดเหตุ ซ้ำ ๆ มากกว่าจะลดข้อบกพร่องในการออกแบบ
  • สำหรับเทคโนโลยีใหม่ การรอและตรวจสอบก่อนนำมาใช้ทันทีอาจปลอดภัยกว่า และผู้ปฏิบัติงานด้านความปลอดภัยควรให้ความสำคัญกับ การออกแบบตามสามัญสำนึก และท่าทีที่ตั้งคำถามมากกว่ากระแส

“แนวคิดตรงข้ามกับแนวคิดที่ดี” ที่ก่อให้เกิดความล้มเหลวด้านความปลอดภัย

  • ในความปลอดภัยคอมพิวเตอร์ มีผลิตภัณฑ์ใหม่ งานประชุมใหม่ หนังสือใหม่ และร่างกฎหมายใหม่ออกมาเรื่อย ๆ แต่ปัญหายังคงเกิดซ้ำ
  • “แนวคิดโง่ ๆ” คือแนวทางที่อยู่ฝั่งตรงข้ามของแนวคิดที่ดี และเกิดขึ้นเมื่อพยายามทำสิ่งที่เป็นไปไม่ได้หรือเพิกเฉยต่อความเป็นจริง
  • แนวทางเหล่านี้บางครั้งมาจากความเข้าใจผิดด้วยเจตนาดี และบางครั้งก็มาจากผลิตภัณฑ์ที่ถูกห่อหุ้มมาอย่างดีเพื่อทำเงินอย่างรวดเร็ว
  • แนวคิดทั้งหกถูกเรียงตามลำดับที่พบเห็นบ่อย และโดยเฉพาะหากหลีกเลี่ยงสามข้อแรกได้ ก็ถือว่าอยู่ในกลุ่มผู้ปฏิบัติงานด้านความปลอดภัยชั้นยอดจำนวนน้อย

1. Default Permit: อนุญาตเป็นค่าเริ่มต้น

  • Default Permit คือวิธีที่อนุญาตทุกสิ่งที่ไม่ได้ห้ามไว้อย่างชัดเจน และเห็นได้ชัดที่สุดในกฎไฟร์วอลล์
    • ผู้ดูแลเครือข่ายยุคแรก ๆ บล็อกเฉพาะ telnet, rlogin, FTP ขาเข้า และอนุญาตอย่างอื่นทั้งหมด
    • ทุกครั้งที่พบช่องโหว่ใหม่ ผู้ดูแลต้องตัดสินใจว่าจะบล็อกหรือไม่ และต้องตามให้ทันก่อนถูกแฮ็ก
    • มันควรจะหายไปพร้อมกับการมาของเวิร์มในทศวรรษ 1990 แต่เครือข่ายจำนวนมากยังมีโครงสร้างแกนกลางแบบเปิดที่ไม่มีการแบ่งย่อย
  • ปัญหาเดียวกันเกิดซ้ำในการรันโค้ด
    • เมื่อผู้ใช้คลิก โดยพื้นฐานแล้วอะไรก็รันได้ และจะถูกปฏิเสธการรันก็ต่อเมื่อแอนติไวรัสหรือตัวบล็อกสปายแวร์หยุดไว้
    • แม้แอปพลิเคชันที่ใช้บ่อยจริง ๆ จะมีราว 15 ตัว และที่ใช้นาน ๆ ครั้งมีราว 20–30 ตัว แต่ระบบปฏิบัติการก็ยังอนุญาตให้ไวรัสหรือสปายแวร์รันได้โดยค่าเริ่มต้น
  • โครงการความปลอดภัย E-banking ใช้แนวทางตรงกันข้าม
    • แทนที่โหลดบาลานเซอร์จะส่งเฉพาะการโจมตีที่รู้จักไปยัง blackhole มันส่งทราฟฟิกทั้งหมดที่ไม่ตรงกับรายการ URL ที่ถูกต้องไปยังเซิร์ฟเวอร์ที่ล็อกไว้ ซึ่งให้บริการรูปภาพและหน้า 404
    • นี่ไม่ใช่ Default Permit ที่บล็อกเฉพาะการโจมตีที่รู้จัก แต่เป็นวิธีปฏิเสธคำขอที่ออกนอกโครงสร้างปกติ
  • หากกำลังอยู่ใน การแข่งขันสะสมอาวุธกับผู้โจมตี นั่นเป็นสัญญาณว่าตกอยู่ใน Default Permit
  • แนวคิดตรงข้ามคือ Default Deny ซึ่งต้องอาศัยความทุ่มเท การคิด และความเข้าใจในการนำไปใช้ แต่เป็นแนวทางที่ดีกว่า

2. Enumerating Badness: การทำรายการสิ่งไม่ดี

  • Enumerating Badness คือวิธีทำรายการสิ่งไม่ดีที่รู้จักทั้งหมด แล้วตรวจจับหรือบล็อกสิ่งเหล่านั้น
  • ตอนแรกดูเหมือนเป็นไปได้เพราะช่องโหว่ด้านความปลอดภัยที่รู้จักยังมีน้อย แต่ตั้งแต่ราวปี 1992 เป็นต้นมา “สิ่งไม่ดี” บนอินเทอร์เน็ตมีมากกว่า “สิ่งดี” อย่างมาก
    • ผลิตภัณฑ์แอนติไวรัสทั่วไปจะรู้จักไวรัสมากกว่า 75,000 ตัว
    • แอปพลิเคชันปกติที่ติดตั้งในคอมพิวเตอร์ส่วนบุคคลหนึ่งเครื่องถือว่ามีประมาณ 30 ตัว
    • หากติดตามแอปพลิเคชันปกติ 30 ตัวและไม่ให้ส่วนที่เหลือรัน ก็จะช่วยลดปัญหาสปายแวร์ ไวรัส โทรจันควบคุมระยะไกล และเอ็กซ์พลอยต์แบบรันโค้ดที่ติดตั้งมาล่วงหน้าแต่ไม่ค่อยได้ใช้ไปพร้อมกัน
  • ตามการวิเคราะห์ของบางฝ่ายในอุตสาหกรรม มี “สิ่งไม่ดี” ใหม่ 200–700 รายการปรากฏบนอินเทอร์เน็ตทุกเดือน
  • ต่อข้อโต้แย้งว่าเครือข่ายองค์กรซับซ้อนจนยากจะทราบว่าแอปพลิเคชันใดเป็นปกติ ผู้เขียนโต้ว่า หาก CTO ไม่รู้คร่าว ๆ ว่าเทคโนโลยีกำลังทำอะไร ก็ไม่สามารถทำแผนกำลังการผลิต แผนภัยพิบัติ หรือแผนความปลอดภัยได้
  • การวิเคราะห์ล็อกของผลิตภัณฑ์ไฟร์วอลล์ในปี 1994 เริ่มจากวิธีค้นหาเงื่อนไขที่ไม่ดี แต่เวอร์ชันที่สองใช้ Artificial Ignorance
    • ทิ้งล็อกที่รู้ว่าไม่น่าสนใจ
    • ล็อกที่เหลือถือว่าน่าสนใจ
    • แนวทางนี้ตรวจพบสภาพการทำงานและข้อผิดพลาดที่ไม่น่าจะคิดขึ้นมาได้เอง
  • แอนติไวรัส ระบบตรวจจับการบุกรุก ระบบป้องกันการบุกรุก ความปลอดภัยของแอปพลิเคชัน และไฟร์วอลล์ตรวจสอบแพ็กเก็ตเชิงลึก มักพึ่งพาวิธีนี้
  • ระบบที่ต้องมี การอัปเดต signature เป็นประจำ หรือปล่อยให้เวิร์มที่ไม่เคยเห็นมาก่อนผ่านไปได้ คือสัญญาณของ Enumerating Badness
  • วิธีรักษาคือ Enumerating Goodness แต่ผู้เขียนเห็นว่าระบบปฏิบัติการแทบไม่มีการรองรับการควบคุมระดับซอฟต์แวร์แบบนี้

3. Penetrate and Patch: เจาะแล้วแพตช์

  • Penetrate and Patch คือวงจรที่โจมตีไฟร์วอลล์ ซอฟต์แวร์ เว็บไซต์ ฯลฯ จากภายนอกเพื่อหาข้อบกพร่อง แก้ข้อบกพร่องนั้น แล้วค้นหาต่ออีกครั้ง
  • วิธีนี้ไม่ได้สร้างระบบที่ดีกว่าโดยการออกแบบ แต่เพียงสร้างระบบที่แข็งขึ้นจากการลองผิดลองถูก
  • Personal Observations on the Reliability of the Space Shuttle ของ Richard Feynman เป็นบทอ่านที่แสดงให้เห็นว่าควรบรรลุความน่าเชื่อถือของระบบซับซ้อนได้อย่างไร
    • สารหลักใกล้เคียงกับว่า “หากไม่ได้ออกแบบระบบให้แฮ็กได้ มันก็ไม่ควรถูกแฮ็กได้”
  • กระแสการเปิดเผยช่องโหว่และการอัปเดตแพตช์ก็อิงกับแนวทางนี้
    • นักวิจัยช่องโหว่มองว่าตนช่วยชุมชน เพราะพบรูรั่วก่อนแฮ็กเกอร์และทำให้มีการแก้ไข
    • ผู้ขายมองว่าตนทำสิ่งที่ถูกต้อง เพราะออกแพตช์ก่อนที่แฮ็กเกอร์และผู้เขียนเวิร์มจะนำไปใช้
    • แต่หากโค้ดถูกออกแบบให้ปลอดภัยและน่าเชื่อถือตั้งแต่ต้น การค้นพบช่องโหว่จะกลายเป็นงานที่น่าเบื่อและให้ผลตอบแทนน้อย
  • หาก Internet Explorer มีบั๊กด้านความปลอดภัยออกมาเดือนละ 2–3 รายการตลอด 10 ปี ก็ยากจะบอกว่า Penetrate and Patch ได้ผล
  • ผู้เขียนเห็นว่าแอปพลิเคชันบางตัว เช่น PostFix และ Qmail ถูกออกแบบให้โมดูลาร์และแบ่งเขตสิทธิ์กับการประมวลผล จึงมีประวัติบั๊กด้านความปลอดภัยน้อยมาก
  • การทดสอบเจาะระบบก็มีข้อจำกัดเดียวกัน
    • เครือข่ายที่การออกแบบพื้นฐานหรือแนวปฏิบัติด้านความปลอดภัยผิดพลาด จะยังถูกแฮ็กซ้ำแม้ผ่านการทดสอบเจาะระบบหลายครั้ง
    • สำหรับเครือข่ายที่ออกแบบตั้งแต่ต้นให้ผ่านได้เฉพาะทิศทางที่กำหนด ทราฟฟิกที่กำหนด และเซิร์ฟเวอร์ที่ตั้งค่าอย่างระมัดระวัง การทดสอบเจาะระบบทั่วไปอาจไม่มีความหมาย
  • หากทุกครั้งยังเปราะบางต่อ “บั๊กประจำสัปดาห์นี้” ก็แปลว่าตกอยู่ใน Penetrate and Patch
  • ซอฟต์แวร์และระบบควรเป็น secure by design และควรถูกออกแบบโดยคำนึงถึงการจัดการข้อบกพร่อง

4. Hacking is Cool: ความคิดว่าแฮ็กกิ้งเป็นเรื่องเท่

  • Hacking is Cool คือการวิจารณ์วัฒนธรรมที่ให้รางวัลหรือยกย่องแฮ็กเกอร์ด้วย stock options หนังสือ คอร์สเรียน และการทดสอบเจาะระบบค่าตัวสูง
  • Donn Parker มองว่าคอมพิวติ้งระยะไกลทำให้การก่ออาชญากรรมไม่จำเป็นต้องอยู่ใกล้ทางกายภาพ และความไม่เปิดเผยตัวตนกับการไม่ต้องเผชิญหน้ากับเหยื่อช่วยลดกำแพงทางอารมณ์ของอาชญากรรม
  • การแฮ็กไม่ใช่ปัญหาทางเทคนิคเท่าไรนัก แต่ใกล้เคียงกับ ปัญหาทางสังคม
    • อินเทอร์เน็ตให้พื้นที่กิจกรรมใหม่แก่คนที่ขาดทักษะทางสังคม
    • หากผู้ปฏิบัติงานด้านความปลอดภัยทำให้แฮ็กเกอร์เป็นฮีโร่ ก็เท่ากับส่งเสริมการแฮ็กโดยนัย
    • สื่อบางครั้งวาดภาพแฮ็กเกอร์เป็น “whiz kids” หรือ “brilliant technologists”
  • การที่ผู้ปฏิบัติงานด้านความปลอดภัยเรียนรู้เทคนิคการแฮ็กก็ถือเป็นส่วนหนึ่งของแนวคิดนี้
    • เอ็กซ์พลอยต์และวิธีใช้จะล้าสมัยอย่างรวดเร็วเมื่อรูรั่วนั้นถูกแพตช์
    • ทำให้ความสามารถเชิงวิชาชีพต้องพึ่งการแข่งขันสะสมอาวุธแบบ Penetrate and Patch
    • การเรียนรู้วิธีออกแบบระบบความปลอดภัยที่ทนต่อการแฮ็ก ย่อมสมเหตุสมผลกว่าการเรียนรู้วิธีค้นหาระบบที่แฮ็กได้
  • ผู้เขียนคาดว่า “Hacking is Cool” จะหายไปภายใน 10 ปี แต่ก็เห็นว่ายังไม่มีสัญญาณว่าแนวคิดตรงข้ามอย่าง “Good Engineering is Cool” จะมาแทนที่

5. Educating Users: การให้ความรู้ผู้ใช้

  • Educating Users ใกล้เคียงกับ Penetrate and Patch ที่นำไปใช้กับมนุษย์
  • ตัวการศึกษาดูเหมือนดี แต่หากได้ผล ก็ควรเห็นผลไปแล้ว
    • มีรายงานว่าหลายงานวิจัยพบว่าผู้ใช้จำนวนมากยอมบอกรหัสผ่านเพื่อแลกลูกอมหนึ่งชิ้น
    • เวิร์ม Anna Kournikova ถูกใช้เป็นกรณีที่แสดงให้เห็นว่ามนุษย์เกือบครึ่งหนึ่งจะคลิกอะไรก็ตามที่ดูเหมือนมีภาพเปลือยของผู้หญิงที่มีชื่อเสียงพอประมาณอยู่ข้างใน
    • หากใช้การให้ความรู้ผู้ใช้เป็นกลยุทธ์ อาจต้อง “แพตช์” ผู้ใช้ทุกสัปดาห์
  • คำถามจริง ๆ ไม่ใช่ “เราจะให้ความรู้ผู้ใช้ให้ปลอดภัยขึ้นได้ไหม” แต่คือ “ทำไมตั้งแต่แรกเราต้องให้ความรู้ผู้ใช้ด้วย”
    • ทำไมผู้ใช้จึงได้รับไฟล์แนบที่เป็นไฟล์ปฏิบัติการ
    • ทำไมผู้ใช้จึงคาดหวังอีเมลจากธนาคารที่ตนไม่มีบัญชี
  • การรับมือไฟล์แนบและฟิชชิงก็เป็นปัญหา Default Permit
    • หากอนุญาตให้ผู้ใช้ทุกคนรับไฟล์แนบอีเมล ก็เท่ากับอนุญาตทุกอย่างที่ถูกส่งมาเป็นค่าเริ่มต้น
    • วิธีที่ดีกว่าอาจเป็นการกักกันไฟล์แนบทั้งหมด ลบไฟล์ปฏิบัติการ และเก็บเฉพาะชนิดไฟล์ที่อนุญาตไว้ใน staging server
    • ให้ผู้ใช้ล็อกอินด้วยเบราว์เซอร์ที่รองรับ SSL เพื่อรับไฟล์ และการขอรหัสผ่านจะทำให้กลไกแพร่กระจายของเวิร์มจำนวนมากอ่อนแรงลงทันที
  • เครื่องมือฟรีอย่าง MIMEDefang สามารถใช้แยกไฟล์แนบออกจากอีเมลขาเข้า เก็บไว้ในไดเรกทอรีรายผู้ใช้ และแทนที่ไฟล์แนบในอีเมลด้วย URL ของไฟล์นั้น
  • ตอนบริหารสตาร์ทอัพด้านความปลอดภัยขนาดเล็ก พนักงานที่ต้องการใช้ Windows ต้องรู้วิธีติดตั้งและดูแลเอง ไม่เช่นนั้นก็จะไม่ถูกจ้าง
  • ผู้เขียนคาดว่าภายใน 10 ปี ผู้ใช้ที่ต้องได้รับการฝึกอบรมจะหลุดออกจากตลาดแรงงานไฮเทค หรือฝึกตนเองที่บ้านเพื่อรักษาความสามารถในการแข่งขัน

6. Action is Better Than Inaction: ความเชื่อว่าการลงมือทำดีกว่าไม่ทำอะไร

  • ผู้บริหาร IT แบ่งได้เป็น “early adopters” กับ “pause and thinkers” และผู้เขียนเห็นว่าฝ่ายที่สร้างระบบ mission critical ที่สำเร็จและปลอดภัยได้นั้นใกล้เคียงกับกลุ่มหลังมากกว่า
  • เมื่อเทคโนโลยีใหม่ออกมา การรอ ดูผลลัพธ์ของผู้ใช้กลุ่มแรกคนอื่น ๆ และค่อยนำไปใช้หลังมีผู้มีประสบการณ์แล้ว อาจปลอดภัยกว่าการติดตั้งทันที
    • ผู้บริหาร IT ระดับสูงคนหนึ่งวางแผนนำเครือข่ายไร้สายในองค์กรมาใช้โดย “รอ 2 ปี แล้วจ้างคนที่เคยติดตั้งระบบไร้สายสำเร็จในบริษัทที่ใหญ่กว่าเรา”
    • ระหว่างนั้น เทคโนโลยีจะเข้าที่มากขึ้นและราคาก็ลดลงมาก
  • ประเด็นประกอบสำคัญคือ “บ่อยครั้ง การไม่ทำเรื่องโง่ ๆ ง่ายกว่าการทำเรื่องฉลาด ๆ”
  • ต่อด้วยคำแนะนำให้เลื่อนการเอาต์ซอร์สด้านความปลอดภัยออกไป 1–2 ปี แล้วฟังคำแนะนำและความเห็นจากองค์กรที่ยังอยู่รอด
  • ในกรณีลูกค้าที่กำลังจะใช้เงินก้อนใหญ่โดยไม่ตรวจสอบ ผู้เขียนแนะนำให้ส่งพนักงานไปงานประชุมที่เกี่ยวข้องอย่าง LISA เพื่อหาคนที่มีประสบการณ์ใช้งานจริง
    • พนักงานคนนั้นสามารถเชิญผู้มีประสบการณ์กับผลิตภัณฑ์ไปกินมื้อเย็นและฟังการประเมินแบบไม่เป็นทางการได้
    • ผู้จัดการ IT เล่าว่าค่าอาหารเย็น 200 ดอลลาร์ช่วยลดความเจ็บปวดทางเทคนิคมูลค่ามากกว่า 400,000 ดอลลาร์
  • “กังฟู” ระดับมืออาชีพคือการหลีกเลี่ยงเรื่องโง่ ๆ ด้วยการไม่ทำอะไรเลย และทำให้หัวหน้ายอมรับความดีความชอบจากการหลีกเลี่ยงนั้น

ความโง่เล็ก ๆ น้อย ๆ อื่น ๆ

  • “เราไม่ใช่เป้าหมาย”
    • เวิร์มไม่ได้ฉลาดพอจะตัดสินว่าเว็บไซต์หรือเครือข่ายบ้านน่าสนใจหรือไม่
  • “ถ้าทุกคนใช้ OS ความปลอดภัยตามกระแสตัวหนึ่ง ก็จะปลอดภัยขึ้น”
    • ระบบปฏิบัติการมีปัญหาความปลอดภัยเพราะมันซับซ้อน และการดูแลระบบก็ยังไม่ใช่ปัญหาที่ถูกแก้แล้ว
    • หากเปลี่ยนตามกระแส ผู้ดูแลอาจยิ่งยากที่จะได้ความเชี่ยวชาญที่สะสมตามเวลา
  • “มีความปลอดภัยบนโฮสต์ที่ดีแล้ว จึงไม่ต้องใช้ไฟร์วอลล์”
    • หากเชื่อถือ network fabric ไม่ได้ แอปพลิเคชันทุกตัวที่วิ่งผ่านเครือข่ายก็เป็นเป้าหมายที่อาจถูกโจมตีได้
    • ตัวอย่างที่ยกคือ Domain Naming System
  • “มีไฟร์วอลล์ที่ดีแล้ว จึงไม่ต้องมีความปลอดภัยบนโฮสต์”
    • หากไฟร์วอลล์ปล่อยทราฟฟิกไปยังโฮสต์ด้านหลัง ก็ต้องพิจารณาความปลอดภัยบนโฮสต์ของระบบเหล่านั้นด้วย
  • “เอาขึ้นโปรดักชันตอนนี้ แล้วค่อยทำความปลอดภัยทีหลัง”
    • หากตอนนี้ไม่มีเวลาทำให้ถูกต้อง ก็ควรถามว่าจะมีเวลาทำใหม่หลังมันพังหรือไม่
    • อาจเกิดสถานการณ์ที่ไม่ยอมใช้เวลาสองสามวันแรก แล้วต้องซ่อมต่อเนื่องหลายปี
  • “ปัญหาที่เกิดเป็นครั้งคราวป้องกันไม่ได้”
    • สิ่งนี้นำไปสู่คำถามย้อนว่า หากอุตสาหกรรมการบินใช้แนวทางแบบนั้นกับชีวิตคน คุณจะกล้าขึ้นเครื่องบินโดยสารเชิงพาณิชย์หรือไม่

ท่าทีที่ผู้ปฏิบัติงานด้านความปลอดภัยต้องมี

  • ผู้เขียนเห็นว่าความปลอดภัยคอมพิวเตอร์หลงใหล “เทคโนโลยีใหม่ประจำสัปดาห์นี้” มากเกินไปจนทิ้งสามัญสำนึก
  • งานของผู้ปฏิบัติงานด้านความปลอดภัยคือการตั้งคำถามต่อความเชื่อทั่วไปและสภาพที่เป็นอยู่ และหากจำเป็นก็ต้องท้าทายอย่างตรงไปตรงมา
  • ปิดท้ายด้วยข้อสังเกตว่า หากความเชื่อทั่วไปได้ผลจริง อัตราการถูกเจาะระบบก็ควรลดลง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-16
ความคิดเห็นจาก Hacker News

  • รู้สึกเหมือนกลับมาคุยเรื่องนี้อีกแล้ว: https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
    บทความนี้มีหลายจุดให้นำมาแยกแยะ แต่สิ่งที่อยากชี้เสมอคือท่าทีที่แท้จริงของ Ranum ต่อ การวิจัยช่องโหว่ นั้นเป็นอย่างไร ช่วงปลายยุค 90 ถึงต้นยุค 2000 Marcus Ranum และ Bruce Schneier เป็นปัญญาชนตัวแทนของจุดยืนที่มองว่าการเปิดเผยช่องโหว่ให้โทษมากกว่าประโยชน์ และงานนี้ควรเป็นหน้าที่ของผู้ขายซอฟต์แวร์ ไม่ใช่นักวิจัยภายนอก มุมมองนั้นสุดท้ายก็พิสูจน์แล้วว่าไม่ถูกต้อง และแม้ในปี 2002 จะยังพอเหมารวมงานวิจัยช่องโหว่แบบเปิดเผยเต็มรูปแบบจากภายนอกไว้ใต้คำว่า “แฮ็กกิง” ได้ แต่ตอนนี้ไม่ใช่แบบนั้นอีกต่อไปแล้ว ทั้ง งานประชุมวิชาการ 4 งานหลัก ของวงการความปลอดภัยรวมถึงวรรณกรรมด้านคริปโตกราฟีก็ล้วนพูดถึงงานวิจัยการโจมตี

    • ตอนนั้นพวกเขาอาจจะถูกก็ได้ ถ้าจะประเมินการตัดสินใจในอดีตอย่างเป็นธรรม ก็ควรดูจากหลักฐานที่มีอยู่ในเวลานั้น หลังจากนั้นขนาดของเครือข่ายและจำนวนผู้เข้าร่วมก็เพิ่มขึ้นแบบระเบิด
    • สงสัยว่าที่ว่า “งานประชุมวิชาการ 4 งานหลัก” ของวงการความปลอดภัย หมายถึงที่ไหนบ้าง
    • เป็นความจริงที่งานวิจัยการโจมตีได้กลายเป็นหัวข้อหลักในงานประชุมสำคัญ ๆ และผลที่ตามมาคือเรายังคงเห็น ผลกระทบภายนอกเชิงลบ ในรูปของการถูกนำไปใช้โจมตีจริงหลังการเปิดเผยอยู่เรื่อย ๆ อีกทั้งผู้ขายหลายรายก็ไม่มีทั้งความสามารถหรือความตั้งใจจะตอบสนองต่อการเปิดเผยจากภาควิชาการอย่างเหมาะสม วงวิชาการเองก็ยังมีพื้นที่ให้ปรับปรุง และแทนที่จะหันกลับไปอีกทาง แนวโน้มที่เป็นไปได้มากกว่าคืองานประชุมหลักจะกำหนดความคาดหวังที่เป็นรูปธรรมมากขึ้นเพื่อลดความเสียหายจากการเปิดเผย เช่น ขยายความหมายของ “ผู้ขาย” ให้รวมถึงผู้ที่สามารถทำมาตรการบรรเทาได้อย่างผู้ขายระบบปฏิบัติการหรือไฟร์วอลล์

  • ไม่แน่ใจว่าตกหล่นไปหรือเปล่า แต่แปลกใจที่ไม่มีการพูดถึง รหัสผ่าน เลย สำหรับผม กฎบังคับเรื่องรูปแบบนอกจากความยาวขั้นต่ำ การบังคับเปลี่ยนเป็นระยะ และความพยายามจะ “แทนที่รหัสผ่าน” ล้วนเป็นไอเดียโง่โดยเนื้อแท้ กฎรูปแบบทำให้คนจดใส่กระดาษ ใช้รหัสผ่านเดิมซ้ำ หรือแค่เติมเลข 1 ต่อท้าย ส่วนวิธีทดแทนก็มัก UX แย่มากหรือชวนสับสน แล้วสุดท้ายก็ย้อนกลับมาใช้รหัสผ่านอยู่ดี แค่ปล่อยให้ผมสร้างรหัสผ่านยาวเกิน X ตัวด้วยอักขระที่ผมเลือกเอง อย่างน้อยผมก็ยังจำมันได้จริงแม้ไม่มีโทรศัพท์หรือคอมพิวเตอร์ หรืออยู่ต่างประเทศ

    • การบังคับเปลี่ยนรหัสผ่านเป็นระยะ อาจเคยเป็นความคิดที่ดีในยุคนั้น หลายสิบปีก่อนแนวปฏิบัติด้านความปลอดภัยแย่มาก เช่น ส่งรหัสผ่านแบบข้อความล้วน และกว่าจะถูกแก้ก็ใช้เวลานาน อีกอย่างยังมีคนที่แชร์รหัสผ่านกันเหมือนลูกอม ซึ่งไม่ได้หมายถึงการแชร์บัญชีสตรีมมิง แต่เป็นการแชร์สิทธิ์เข้าถึงทรัพยากรสำคัญภายในองค์กรกับเพื่อนร่วมงาน ดังนั้นผมจึงไม่เห็นด้วยกับการมองข้ามการอบรมผู้ใช้ปลายทาง แม้บางอย่างจะแก้ได้ด้วยเทคนิค แต่ปัญหาทางสังคมอย่างการแชร์รหัสผ่านมักแก้ด้วยเทคโนโลยีอย่างเดียวได้ไม่ดีนัก
    • ที่ไหนก็ตามที่ยังแนะนำให้บังคับเปลี่ยนรหัสผ่านทุกเดือนหรือทุกสองเดือน มักเป็นที่ที่ตามแนวปฏิบัติด้านความปลอดภัยล่าสุดของหน่วยงานกำกับดูแลไม่ทัน ทั้ง NIST ของสหรัฐฯ (https://pages.nist.gov/800-63-FAQ/) และ NCSC ของสหราชอาณาจักร (https://www.ncsc.gov.uk/collection/passwords/updating-your-a...) ต่างก็ออกแนวทางที่ค่อนข้างดีซึ่งไม่มีข้อกำหนดแบบนั้น
    • ผมพูดข้อความนี้มาหลายปีแล้ว ตัวสร้างรหัสผ่านนั้นแทบจะสร้างกุญแจที่จำไม่ได้เลย และผลก็คือเกิดตัวจัดการรหัสผ่านขึ้นมา ซึ่งทั้งหมดนี้ก็ถูกปกป้องด้วยรหัสผ่านเพียงอันเดียว ตอนนี้จุดล้มเหลวจุดเดียวจึงกลายเป็น รหัสผ่านหนึ่งอัน และถ้าผู้โจมตีได้มันไป ก็เข้าถึงรหัสผ่านทั้งหมดได้อยู่ดี ที่จริงกฎล็อกหลังลองผิด n ครั้งตัดเส้นทางการโจมตีแบบ brute force ออกไปได้ในกรณีส่วนใหญ่ ซึ่งมีประสิทธิภาพกว่ามาก ผมไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัย จึงอาจมีกรณีที่รหัสผ่านยาวและซับซ้อนสร้างความต่างได้ แต่ถ้ามีการยืนยันตัวตนหลายปัจจัย การถกเถียงส่วนใหญ่ในเรื่องนี้ก็แทบไม่มีความหมาย
    • เดิมก็จะพูดถึงรหัสผ่านเหมือนกัน แต่ตอนนี้ passkey ดูเหมือนจะเป็นผู้เข้าชิงไอเดียที่โง่ยิ่งกว่า สำหรับผู้ใช้ทั่วไปมันน่าจะสร้างความสับสนไม่รู้จบ
    • นโยบายรหัสผ่านนี่เหมือนเรื่องตลก ใช้เว็บ 5 แห่งก็เจอนโยบาย 5 แบบ ที่อย่างธนาคารบางแห่งถึงขั้นบล็อกอักขระพิเศษเพราะมองว่าเป็น “ความพยายามแฮ็ก” จนตัวสร้างรหัสผ่านของ Firefox ยังใช้ไม่ได้ แล้วผู้ใช้ก็เลยหาทางอ้อมด้วยการใส่อะไรอย่าง suckmyDICK123!! เข้าไป ถึงอย่างนั้นปกติแล้วระบบก็มักมีอัตรารับมือ brute force ไม่พอ หรือไม่ก็ล็อกบัญชีหลังผิด 5 ครั้ง เลยไม่ได้ถูกเจาะง่ายนัก ทุกวันนี้คนส่วนใหญ่ก็พอรู้กันแล้วว่า “บอตลองรหัสผ่านได้เร็วเหนือมนุษย์” และไม่มีนโยบายรหัสผ่านแบบไหนที่หยุดการเลือกรหัสผ่านแย่ ๆ ได้ กรณีแบบนี้คือคนที่ “รับผิดชอบ” กำลังเสียเวลาอย่างมหาศาลไปกับการพยายามแก้ปัญหาโลกจริง ยกเว้นบัญชีสำคัญจริง ๆ อย่างธนาคารสักหนึ่งสองแห่ง ผมก็อยากใช้รหัสผ่านเดียวกันกับบริการที่บังคับสมัครแบบฝืน ๆ อย่างเกม 80 เกมที่ลองเล่นไปแค่นาทีเดียว บางทีมันยังเป็น GUI แยกจนวางก็ไม่ได้ด้วย จะใช้ตัวจัดการรหัสผ่านก็ได้แหละ แต่ก็ไม่มีเหตุผลมากพอให้ต้องทำ

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

    • คุณอาจบอกได้ว่าอาชญากรรมไม่เท่ แต่การรู้เรื่องอย่างการสะเดาะกุญแจ การสตาร์ตรถแบบจั๊มสาย การสร้างอาวุธ หรือการรัน John the Ripper นั้นมีเสน่ห์แบบล้มล้างกฎอยู่จริง ๆ มันให้ความรู้สึกเหมือนเป็นพ่อมดชนิดหนึ่ง ที่ไม่ถูกผูกมัดด้วยกฎที่ทุกคนเชื่อ
    • ถ้าคอมพิวเตอร์ปลายทางถูกใช้โดยแก๊งคอลเซ็นเตอร์หลอกลวงเพื่อเก็บข้อมูลส่วนตัวของเหยื่อผู้สูงอายุจำนวนมาก การเข้าถึงโดยไม่ได้รับอนุญาตก็อาจเท่ได้ ถ้าการเข้าถึงนั้นรบกวนธุรกิจต้มตุ๋น มันอาจทั้งเท่มากและตลกมากด้วย ในทางเทคนิคมันผิดกฎหมายและเข้าข่ายความยุติธรรมแบบศาลเตี้ย แต่ที่พูดกันตรงนี้ไม่ใช่เรื่องความชอบด้วยกฎหมาย แต่เป็นเรื่อง “ความเท่” ต่างหาก และพวกศาลเตี้ยมักดูเท่เมื่อขับเคลื่อนด้วยความยุติธรรมส่วนบุคคล

  • บทความนี้มีการตัดสินที่แย่มากอยู่หลายจุด ประโยคทำนองว่า “ระบบของฉันออกแบบ พัฒนา และตั้งค่าอย่างรอบคอบแล้ว จึงไม่จำเป็นต้องทดสอบ” อาจเป็นมุมมองด้านความปลอดภัยที่แย่ที่สุดที่ผมเคยได้ยินมาเลยก็ได้ ส่วนคำว่า “การแฮ็กเป็นปัญหาทางสังคม ไม่ใช่ปัญหาทางเทคนิค” ก็ใกล้เคียงกับ การพึ่งพาความลับเพื่อความปลอดภัย และก็ไม่ได้เป็นปัญหาทางสังคมเสมอไปด้วย ดูเรื่องจารกรรมองค์กรหรือผู้กระทำการระดับรัฐก็ชัดเจนว่าไม่ใช่

  • ปัญหาหลักมักเป็นการประนีประนอมที่น่าเศร้าระหว่าง การใช้งาน vs ความปลอดภัย และตัวอย่างแนวคิดโง่ ๆ ส่วนใหญ่ที่ยกมาในที่นี้ก็เป็นผลจากการลดความไม่สะดวกของผู้ใช้ทั่วไปโดยยอมเสียความปลอดภัยไป ตัวอย่างเช่น การอนุญาตเป็นค่าเริ่มต้นนั้นแย่มากสำหรับความปลอดภัยและเป็นสาเหตุของปัญหามากมายใน Windows แต่ผู้ใช้ก็ไม่ชอบการต้องกดยืนยันอนุญาตอย่างชัดเจนทุกครั้งที่มีโปรแกรมใหม่ แม้แต่ตอนที่ Microsoft เพิ่มหน้าต่างยืนยัน หลายคนก็ยังมองว่าเป็นการออกแบบที่แย่และทำให้ซอฟต์แวร์น่ารำคาญขึ้นมาก ดังนั้น “อนุญาตเป็นค่าเริ่มต้น”, “ระบุรายการสิ่งไม่ดี”, และ “ค่อยแพตช์หลังถูกเจาะแล้ว” จึงกลายเป็นค่าปริยาย โดยส่วนตัวแล้วผมมองว่า รหัสผ่าน เองก็เป็นหนึ่งในแนวคิดที่โง่ที่สุดในด้านความปลอดภัย เพราะนิยามของรหัสผ่านที่ดีก็คือจำยาก พิมพ์ยากบนอุปกรณ์ที่ไม่มีคีย์บอร์ดที่เหมาะสม และสร้างความไม่สะดวกแก่ผู้ใช้แทบทุกด้าน แต่ในความเป็นจริงก็ยังไม่มีทางเลือกที่ดีกว่า ลิงก์ทางอีเมลก็พังหมดถ้าสิทธิ์เข้าถึงอีเมลโดนขโมย และการรีเซ็ตรหัสผ่านก็มักเป็นแบบเดียวกัน อุปกรณ์ยืนยันตัวตนแบบกายภาพก็ทำให้ผู้ใช้ล็อกอินนอกบ้านไม่ได้หรือไม่ก็ต้องพกของติดตัวตลอดเวลา และแทบทุกวิธีก็ยังต้องอาศัยวินัยด้านความปลอดภัยที่ดี ทั้งที่คน 99.9% แทบไม่สนใจ

    • จากข้อสังเกตนั้นจึงเกิด passkey ขึ้นมา ซึ่งมีองค์ประกอบของการล็อกอินด้วย single sign-on และ 2FA เท่านั้น Apple ผสาน passkey ที่ซิงก์ผ่านคลาวด์เข้ามาอย่างสมบูรณ์ และบนอุปกรณ์ Apple มันทำงานได้ภายในอุปกรณ์ และถ้าคุณมีอุปกรณ์ Apple ก็ใช้เพียง 2FA ได้ Chrome ก็ทำหน้าที่เป็น passkey ได้ และ BitWarden ก็เช่นกัน มันหลอกไม่ได้ เลี่ยงไม่ได้ เลือกผู้ให้บริการได้ และยังบอกชื่อผู้ให้บริการที่เว็บไซต์ลงทะเบียนไว้ได้ด้วย จึงไม่มีอะไรต้องจำ
    • ขอแนะนำให้ใช้ ตัวจัดการรหัสผ่านบนเบราว์เซอร์ ที่มีชื่อเสียงและปกป้องมันด้วยรหัสผ่านที่แข็งแรง แล้วปล่อยให้มันสร้างรหัสผ่านที่แข็งแรงซึ่งคุณไม่ต้องท่องจำ เว็บไซต์ที่ใช้ JavaScript ในช่องกรอกรหัสผ่านเพื่อขัดขวางสิ่งนี้ควรถูกเรียกค่าเสียหายและลงโทษเพิ่ม โดยเฉพาะพวกธนาคาร
    • รหัสผ่านเคยเป็นแนวคิดที่ดีอยู่เป็นเวลานาน ช่วง 10 ปีแรก หรืออาจ 20 ปีแรกนั้นยังไม่มีอุปกรณ์ที่ไม่มีคีย์บอร์ดที่เหมาะสม ปัญหาใหญ่กว่าคือแนวคิดที่ว่ารหัสผ่านต้องซับซ้อนและยาว เช่น ต้องผสมตัวอักษร ตัวเลข และอักขระพิเศษแบบสุ่มให้เกิน 12 ตัว ทั้งที่การใช้หลายคำกลับดีกว่า เรามักประเมินต่ำไปว่าโลกเทคโนโลยีเปลี่ยนไปมากแค่ไหนหลังสมาร์ตโฟนเข้ามา แต่ในยุคคอมพิวเตอร์และแล็ปท็อปก่อนหน้านั้น รหัสผ่านถือเป็นทางเลือกที่ดี

  • คำพูดที่ว่า “การเรียนรู้ exploit หลายแบบและวิธีใช้มัน ก็คือการเสียเวลาเรียนรู้เครื่องมือและเทคนิคที่จะล้าสมัยเมื่อมีแพตช์ออกมา” นั้นไม่ถูกต้อง จริง ๆ แล้วมันคือการเรียนรู้ ภาคปฏิบัติพร้อมทฤษฎี และมีประโยชน์มาก

    • ผมก็คิดว่าส่วนนี้มีปัญหาเหมือนกัน คุณจะเป็นนักเขียนไม่ได้ถ้าไม่เคยเรียนรู้การอ่าน การที่มีคนตีพิมพ์หนังสือไม่ได้ทำให้ประโยชน์ของการอ่านลดลง คุณต้องเรียนรู้ว่า exploit ที่รู้จักกันแล้วทำงานอย่างไร จึงจะค้นพบ exploit ที่ยังไม่รู้จักได้ ต่อให้ช่องโหว่ที่รู้จักถูกแพตช์ไปแล้ว คุณค่าของความรู้เรื่องวิธีที่มันเกิดขึ้นก็ไม่ได้ลดลง มันอาจใช้ไม่ได้อีกต่อไป แต่ตั้งแต่แรกจุดประสงค์ของการเรียนก็คงไม่ใช่เพื่อเอามันไปใช้โดยตรงอยู่แล้ว
    • ก็ไม่เสมอไป ยังมี script kiddie จำนวนมากที่ใช้ LOIC ทำเว็บล่มได้ทั้งที่ไม่รู้เลยว่า TCP คืออะไร หรือ HTTP request หน้าตาเป็นอย่างไร

  • ในรายการนี้ผมจะเอา “การแฮ็กนั้นเท่” ออก แล้วใส่ การเชื่อถือไคลเอนต์ เข้าไปแทน ช่วงหลังมีความพยายามจะเชื่อถือไคลเอนต์มากขึ้น เช่น แอปมือถือที่要求ให้พิสูจน์ว่าระบบปฏิบัติการไม่ได้ถูกแก้ไข หรือกรณีที่ Google พยายามใส่ DRM คล้าย ๆ กันลงในเว็บ หากโมเดลความปลอดภัยเครือข่ายต้องพึ่งการเชื่อถือซอฟต์แวร์ฝั่งไคลเอนต์ มันก็พังไปแล้ว

    • นั่นไม่ใช่เรื่องความปลอดภัย แต่เป็นเรื่องของ การควบคุม ระบบที่ถูกดัดแปลงอาจถูกใช้เพื่อจุดประสงค์ชั่วร้ายอย่างการบล็อกโฆษณา และ Google ก็คงไม่ชอบสิ่งนั้น

  • มีคำพูดเกี่ยวกับ “ปฏิเสธเป็นค่าเริ่มต้น” ว่า “มันไม่ได้ยากกว่าอนุญาตเป็นค่าเริ่มต้นมากนัก และทำให้นอนหลับสบายขึ้นตอนกลางคืน” ซึ่งเจ้าหน้าที่ความปลอดภัยไอทีอาจนอนหลับดีขึ้น แต่คนที่เหลือทั้งบริษัทจะหงุดหงิดมากเพราะทำอะไรไม่ได้เลยถ้าไม่ต้องไปกลับกับฝ่ายไอทีสามรอบ และยิ่งคนหงุดหงิดมากเท่าไร ก็ยิ่งมีแนวโน้มจะใช้ทางลัดที่บ่อนทำลายแนวคิดด้านความปลอดภัยมากขึ้น เช่น ถ้าบังคับเปลี่ยนรหัสผ่านทุกเดือน คนก็จะใช้ password1, password2, password3 กัน ความปลอดภัยไอทีที่ดีไม่ใช่แค่การดึงสายแลนออก แต่ควรเป็นสิ่งที่ มองไม่เห็นและไม่รบกวน ผู้ใช้ราวกับเวทมนตร์

    • แอปของผู้ขายรายหนึ่งที่สำคัญมากของแผนกเพื่อนผมหยุดทำงานขึ้นมา เขาจึงเปิด ticket กับไอที แต่เรื่องมันซับซ้อนเกินไป สุดท้ายเลยได้รับอนุญาตให้รัน Microsoft packet capture พอจับแพ็กเก็ตแล้วไอทีก็ยังแก้ไม่ได้ เลยส่งมาหาผมด้วยความหงุดหงิด ผมเป็นนักพัฒนา จึงมีสิทธิ์แอดมินและ MSDN บนแล็ปท็อป พอดาวน์โหลดเครื่องมือของ Microsoft มาดู capture ก็พบว่าแอปนั้นเป็น การติดตั้ง client/server อยู่ภายในเครื่อง local โดย frontend คุยกับ backend ผ่านพอร์ตเครือข่าย และ backend คุยกับเซิร์ฟเวอร์ของผู้ขายอีกที หลังจากบริษัทเริ่มใช้นโยบาย “ปฏิเสธเป็นค่าเริ่มต้น” เวิร์กโฟลว์การพัฒนาของผมก็พังไปหลายทาง และผมเองก็หาวิธีเลี่ยงที่ไอทีไม่รู้ ผมบอกเขาแล้วว่าต้องแจ้งอะไรและจะ whitelist อย่างไรได้บ้าง แต่เขาก็ยังมีปัญหาอยู่ ที่เล่ารายละเอียดแบบคลุม ๆ ไม่ใช่เพราะความลับอย่างเดียว แต่เพราะเพื่อนผมทำงานกับไอทีมากว่าหนึ่งปีกว่าจะมาถึงจุดนี้ และนั่นก็เป็นเรื่องเมื่อสองปีก่อนแล้วจนลืมรายละเอียดไปมาก ถ้าคุณเริ่มใช้นโยบาย “ปฏิเสธเป็นค่าเริ่มต้น” ในบริษัทผู้ผลิตแบบ legacy การบอกว่า “เพิ่มการไปกลับอีก 3 รอบ” ยังถือว่าประเมินต่ำไป
    • ผมอยากให้ผู้ดูแลไอทีหันมาใช้โมเดลความปลอดภัยแบบ เข็มขัดนิรภัยและถุงลมนิรภัย มากกว่านี้ ตอนใช้งานรถตามปกติ มันสร้างความไม่สะดวกเพียงเล็กน้อย แต่เมื่อเกิดอุบัติเหตุ คุณค่าของมันมหาศาล ทว่าผู้ดูแลจำนวนมากกลับมองว่าการขัดขวางงานโดยตรงเป็นเรื่องปกติ เพื่อปกปิดความไม่รู้และความไม่เป็นมืออาชีพของตนเอง
    • ความปลอดภัยไอทีที่ดีไม่ใช่สิ่งที่มองไม่เห็น มันมีไว้เพื่อหยุดการปล่อยใช้งานแอปพลิเคชันห่วย ๆ ที่ต้องการสิทธิ์เข้าถึงอินเทอร์เน็ตขาออกแบบไม่จำกัด ต้องผลักดัน multi-factor authentication และทำงานร่วมกับผู้มีส่วนได้ส่วนเสียตั้งแต่แรกเพื่อให้มีความปลอดภัยตั้งแต่เริ่มต้น ส่วนใหญ่แล้วมันคือการระบุและลดความเสี่ยงทางธุรกิจ ควรคำนึงด้วยว่าแอปพลิเคชันทุกตัวถูกมองว่าเป็นองค์ประกอบที่ต้องรับผิดชอบ และแอปใหม่ที่ออกนอกมาตรฐานต้องจัดการเป็นกรณี ๆ ไป
    • ผมคิดว่านโยบาย “ปฏิเสธเป็นค่าเริ่มต้น” เป็นความคิดที่ดีสำหรับโครงสร้างพื้นฐานด้านความปลอดภัยรอบ ๆ เวิร์กสเตชัน เมื่อมีเครื่องมือใหม่ที่ใช้พอร์ตใหม่ ๆ ภาระที่ไอทีต้องปรับ security profile นั้นต่ำกว่าต้นทุนจากการที่ข้อมูลในเวิร์กสเตชันบางเครื่องรั่วไหลมาก อย่างไรก็ตาม ผมคิดว่าเซิร์ฟเวอร์แอปพลิเคชันและโครงสร้างพื้นฐานสาธารณะต้องทำงานแบบปฏิเสธเป็นค่าเริ่มต้นแน่นอน นึกแทบไม่ออกว่ามีกรณีไหนที่ไม่ควรเป็นเช่นนั้น
    • ไอทีของบริษัทมีไว้เพื่อบริษัท ต้นทุนต้องไม่สูงกว่าผลประโยชน์ ต้องมีความสมดุล ไม่ควรใช้เวลาหนึ่งสัปดาห์เพื่อเปิดพอร์ตเดียว แต่ก็ไม่อยากให้คนมารันเว็บเซิร์ฟเวอร์บนเดสก์ท็อปของบริษัท แล้วบังเอิญมีไฟล์แผนงานกรรมสิทธิ์วางอยู่ข้าง ๆ ด้วย

  • บทความสายความปลอดภัยมักเขียนโดยคนที่ให้ความสำคัญกับความปลอดภัยอย่างสุดโต่ง และบ่อยครั้งก็มองข้ามความลำบากที่แนวทางแบบเน้นความปลอดภัยล้วน ๆ สร้างให้กับผู้ใช้ซอฟต์แวร์ที่ปลอดภัย ความปลอดภัยควรถูกมองเป็น สไลเดอร์ระหว่างความปลอดภัยกับความสะดวกสบาย เสมอ การออกแบบที่ปลอดภัยสมบูรณ์แบบอาจใช้งานไม่สะดวกเกินไปจนแทบไม่มีใครใช้ ส่วนการออกแบบที่สะดวกสมบูรณ์แบบก็ไม่ปลอดภัยพอและสุดท้ายอาจจบลงแบบเดียวกัน ถึงอย่างนั้นบทความนี้โดยรวมก็ยังพออ่านได้ แต่ฉันไม่เห็นด้วยอย่างยิ่งกับความคิดที่ว่าการให้ผู้เชี่ยวชาญด้านความปลอดภัยลองเขียน exploit หรือเรียนรู้วิธีโจมตีระบบใดระบบหนึ่งเป็นเรื่องโง่ ๆ ฉันเรียนรู้เรื่องความปลอดภัยจากการศึกษาช่องโหว่และ exploit รวมถึงลงมือทำแบบ white hat ด้วยตัวเอง มากกว่าจากการเรียนแค่เรื่อง “การออกแบบที่ปลอดภัย” เสียอีก คล้ายกับคำพูดที่ว่า “ถ้าอยากรู้จักมัน ก็ต้องลองเป็นมันดู”

    • เปรียบเทียบแบบนี้อาจเข้าถึงง่ายกว่า แต่ฉันมักพูดตรงกว่านั้นนิดหน่อย เวลาเถียงกับคนที่เอาแต่ท่องเรื่องความปลอดภัย ฉันมักเริ่มด้วยประโยคอย่าง “สิ่งที่ปลอดภัยที่สุดคงเป็นการปิดร้านพรุ่งนี้เลย แต่คงขออนุมัติยากหน่อยใช่ไหม” พอหัวเราะกันแล้วค่อยคุยกันว่าจะประนีประนอมตรงไหน อีกวิธีหนึ่งที่ฉันเคยใช้ได้ผลคือเปลี่ยนกรอบสนทนาเป็น “ถ้าคุณบอกว่าไม่ได้ ฉันก็จะทำโดยไม่มีพวกคุณอยู่ดี และตอนนั้นความปลอดภัยก็จะมีเท่าที่ฉันใส่เข้าไปเอง ยังไงก็มีทางทำได้เสมอ เพราะงั้นช่วยพาไปทางที่ปลอดภัยกว่าน่าจะดีกว่า” แต่ฉันพยายามเลี่ยงวิธีนี้เพราะมันสร้างแรงต้านได้ง่าย

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

    • ถ้าจะตีความในแง่ดีที่สุด สิ่งที่ผู้เขียนน่าจะพยายามจะพูดคือปัญหาของการทำ “แพตช์” ที่เจาะจงแคบเกินไป โดยไม่ไปแก้แนวปฏิบัติด้านการออกแบบที่ผิดพลาดซึ่งเป็นต้นเหตุของช่องโหว่ เช่น กรณี “แก้” ช่องโหว่ cross-site scripting ในเว็บแอปด้วยการบล็อกคำขอที่มีคีย์เวิร์ดอย่าง script หรือ onclick
    • นี่คือตัวอย่างของการที่พอพูดอะไรโง่ ๆ อย่างมั่นใจ คนจำนวนมากกลับคิดว่าฉลาด
    • ตัวบทความเองก็โง่อย่างโจ่งแจ้ง ประโยคที่ว่า “คนขี้ขลาดก็อาจกลายเป็นอาชญากรได้” แสดงความเข้าใจผิดทั้งเรื่องการแฮ็ก ความเป็นอาชญากรรม และธรรมชาติของมนุษย์ อาชญากรไปหาที่ที่มีเงินอยู่เสมอ และการใช้ปืนจ่อหน้า ATM เพื่อปล้นเงินก็ไม่ได้ต้องเป็นนักมวยปล้ำร่างยักษ์ เช่นเดียวกับการจะเข้าใจคอมพิวเตอร์ก็ไม่ได้ต้องเป็นเนิร์ดตามภาพจำ นี่มันโง่ระดับหนังตลกห่วย ๆ จากยุค 1980 เลยทีเดียว ประโยคที่ว่า “การประมวลผลระยะไกลทำให้อาชญากรไม่จำเป็นต้องอยู่ใกล้สถานที่เกิดเหตุเหมือนในอดีต” ก็ไม่สมเหตุสมผล ลองคิดดูว่ายุคไปรษณีย์ทำให้เกิดอะไรได้บ้าง การหลอกลวงแบบ Spanish Prisoner มีมาตั้งแต่หลายศตวรรษก่อนแล้ว และมีโครงสร้างเดียวกับ 419 scam การบอกว่านิรนามและการไม่ต้องเจอเหยื่อหน้าตรงช่วยลดความยากทางอารมณ์ของการก่ออาชญากรรมก็เป็นการพูดเกินจริง อาชญากรสามารถฉ้อโกง ใช้ความรุนแรง หรือข่มขู่ให้ล้างบัญชีได้แม้จะเห็นหน้ากัน สุดท้ายแล้วคำว่า “ทำให้ถูกต้องสมบูรณ์ตั้งแต่แรกสิ ไอ้โง่” ก็ไม่ใช่แผนที่นำไปปฏิบัติได้จริง
    • การอัปเดตบ่อยมักช่วยกลบแนวปฏิบัติทางวิศวกรรมที่ไม่เหมาะสม และยิ่งกระตุ้นให้มีผลิตภัณฑ์ที่ไม่เหมาะสมออกมา โลกไม่หยุดนิ่งก็จริง แต่สิ่งส่วนใหญ่มีรูปแบบที่ควรระบุและจัดการให้ได้ ถ้ามัวแต่วิ่งจากการแก้ด่วนของ MVP ไปสู่การแก้ด่วนครั้งถัดไป ก็ไม่มีทางหาเวลามาทำเรื่องนั้นได้
    • มันก็มีแก่นสารที่มีคุณค่าอยู่บ้างไม่กี่จุด แต่แค่อย่างน้อยครึ่งหนึ่งก็ดูเหมือนคำบ่นยาวน่าอายที่น่าจะได้ยินจากเด็กฝึกงาน helpdesk หน้าใหม่ที่เมาปลายงานเลี้ยงบริษัท การที่มันเขียนโดยผู้เชี่ยวชาญเฉพาะทาง ถูกแขวนไว้บนเว็บไซต์ของตัวเองมา 20 ปี และยังถูกแนะนำกันมากขนาดนั้น เป็นเรื่องน่าตกใจ