CrowdStrike คว้ารางวัล PwnieAwards สาขา "Most Epic Fail" ที่งาน Defcon

 (twitter.com/singe)
1 คะแนน โดย GN⁺ 2024-08-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

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

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

 
GN⁺ 2024-08-12
ความคิดเห็นบน Hacker News

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

    • วิศวกรรมโยธาต่างออกไปตรงที่ออกแบบผลิตภัณฑ์ทางกายภาพ ไม่มีอะไรถูกออกแบบให้เฉียดขีดจำกัดพอดี และทุกอย่างมี ส่วนเผื่อความปลอดภัย มากพอ
      เช่น คำนวณสะพานที่มีรถบรรทุกวิ่งแน่นในสถานการณ์ที่เกิดแผ่นดินไหวระหว่างพายุเฮอร์ริเคน แล้วบวกเพิ่มไปอีก 20% ถ้าไม่มั่นใจว่าคานจะรับไหว ก็ทำให้ใหญ่ขึ้น และต่อให้คำนวณผิด 0.5% ก็ไม่ใช่ปัญหาใหญ่
      ถ้าเอกสารออกแบบพิมพ์ผิดจนจะเอาคาน 150 ฟุตใส่ในช่องว่าง 15.0 ฟุต ผู้รับเหมาก่อสร้างก็จะถามกลับเพื่อยืนยัน ดังนั้นการพังของสะพานแทบจะแน่นอนว่าเป็นผลจากความประมาทเลินเล่ออย่างร้ายแรง
      ตรงกันข้าม ในการเขียนโปรแกรม แค่ใส่ < ตัวเดียวแทน <= ก็อาจเป็นเส้นแบ่งระหว่างระบบที่ทำงานปกติกับความเสียหายหลายพันล้านดอลลาร์ได้ ไม่มีโปรแกรมเมอร์คนใดบนโลกที่สามารถเขียนแอปพลิเคชันที่มีความซับซ้อนระดับไม่เล็กน้อยให้ ไร้ข้อบกพร่อง 100% ได้
      แม้แต่ไมโครเคอร์เนล seL4 ที่ชูเรื่องการพิสูจน์ความถูกต้องอย่างเป็นทางการก็ยังมีบั๊ก คอมไพเลอร์และตัวตรวจสอบพิสูจน์นั้นเป็นไปได้ในเชิงเทคนิค แต่ถ้าสั่งให้ทำสิ่งที่ผิดอย่างชัดเจน มันก็ไม่บ่น
      การยอมรับความรับผิดแบบแทบไม่จำกัดต่อความผิดพลาดที่เล็กที่สุด ไม่ใช่สิ่งที่คนปกติจะรับได้
      หากต้องการเอาผิดวิศวกรซอฟต์แวร์ ก่อนอื่นต้องหาวิธีแยกระหว่างความผิดพลาดโดยสุจริตที่เกิดขึ้นได้ทั่วไปกับ ความประมาทเลินเล่ออย่างร้ายแรง ซึ่งน่าจะทำให้เป็นรูปแบบทางการได้ยากมาก
    • หลังจาก Delta เตือนว่าจะฟ้องเรียกค่าเสียหาย 500 ล้านดอลลาร์ CrowdStrike ตอบอย่างเปิดเผยว่า ตามสัญญาแล้วเพดานความรับผิดของ CrowdStrike อยู่ที่ หลักล้านดอลลาร์เลขหลักเดียว
      จากนั้นยังส่งรายการไปว่า หากเริ่มฟ้องร้อง จะขอในขั้นตอนเปิดเผยพยานหลักฐานทั้งแผนสำรอง แผน failover ตารางและผลการทดสอบ รวมถึงเวลาครั้งล่าสุดที่ซ้อมกู้คืนจากแบ็กอัป
      โดยสาระคือ “ถ้าฟ้อง เราจะขุดคุ้ยแนวปฏิบัติด้าน IT ของพวกคุณลึกจนทำให้พวกคุณอับอายยิ่งกว่าเรา และจะแสดงให้เห็นว่าความผิดอยู่ที่พวกคุณเอง”
    • มีช่องทางเยียวยาอยู่ แต่ก็อย่างที่ว่า ไม่ใช่สำหรับคนทั่วไป บริษัทต่าง ๆ กำลังฟ้อง CrowdStrike และจะยังฟ้องต่อไป และดูจากเอกสารที่ CrowdStrike เปิดเผย บริษัทที่เสียหายน่าจะมีโอกาสชนะสูงมาก
      ดูมีแนวโน้มสูงว่าจะโน้มน้าวผู้พิพากษา คณะลูกขุน หรืออนุญาโตตุลาการได้ว่า CrowdStrike กระทำ ความประมาทเลินเล่ออย่างร้ายแรง และทำให้บริษัทเหล่านั้นเกิดความเสียหายโดยตรง รวมถึงความเสียหายทางชื่อเสียงโดยอ้อมอย่างชัดเจน
      พูดตรง ๆ ก็ไม่แน่ใจว่า CrowdStrike จะสู้จนถึงที่สุดหรือไม่ ส่วนใหญ่คงจบด้วยการยอมความนอกศาล และในอีกไม่กี่ปีข้างหน้าเราอาจได้เห็น CrowdStrike ค่อย ๆ พังลง
    • หลายบริษัทมีประกันสำหรับเหตุการณ์ที่ทำให้แหล่งรายได้หยุดชะงักอยู่แล้ว เหมือนประกันพืชผลของเกษตรกรหรือประกันภัยพิบัติของร้านค้าปลีกขนาดใหญ่ กรณีโครงสร้างพื้นฐานล่มจนรายได้เป็นศูนย์ชั่วระยะหนึ่ง ก็น่าจะมีอะไรบางอย่างรองรับ
      ต่อให้ทุกคนที่ได้รับผลกระทบเรียกค่าเสียหาย 100% จาก ClownStrike รายได้ของ ClownStrike ก็ไม่พอชดใช้ความเสียหายนั้น ต่อให้อยากทำให้บริษัทปิดกิจการ ก็เรียกคืนเงินได้ไม่ใกล้เคียงกับความเสียหายจริง
      ดังนั้นจึงสงสัยว่าจริง ๆ แล้วจะเสนออะไร โค้ดไร้บั๊ก แทบเป็นไปไม่ได้ และความเสี่ยงบางส่วนก็เป็นสิ่งที่ผู้ใช้ยอมรับเอง
      คุณคิดจริง ๆ หรือว่าก่อนนำซอฟต์แวร์ไปใช้ มันต้องไม่มีบั๊ก 100%? แล้วจะพิสูจน์อย่างไร? ถ้าอย่างนั้นคำถามต่อมาก็คือ โค้ดของคุณเองสะอาดแค่ไหนถึงคิดว่าสิ่งนั้นเป็นไปได้
    • เป็นไปได้ แต่คำตอบคือ เวลา วิศวกรรมโยธามีประวัติศาสตร์ยาวนานหลายพันปี ส่วนวิศวกรรมซอฟต์แวร์ยังอายุน้อยกว่ามาก และรากฐานของสาขานี้ก็ยังเปลี่ยนแปลงอยู่
      อย่างน้อยในประเทศของผม ตั้งแต่ปลายทศวรรษ 1970 ก็มีร่างกฎหมายระบบใบอนุญาตสำหรับนักวิเคราะห์ระบบ โปรแกรมเมอร์คอมพิวเตอร์อิเล็กทรอนิกส์ ผู้ควบคุมเครื่องประมวลผลข้อมูล และพนักงานพิมพ์ดีด(!)
      ถ้ากฎหมายเหล่านี้ผ่าน การพัฒนาซอฟต์แวร์ในประเทศเราคงล้าหลังไปหลายสิบปี ตัวอย่างเช่น ร่างกฎหมายฉบับหนึ่งพยายามกำหนดให้ “การควบคุมและใช้งานอุปกรณ์หรือเครื่องประมวลผลอิเล็กทรอนิกส์ รวมถึงเทอร์มินัล (อุปกรณ์ดิจิทัลหรืออุปกรณ์แสดงผล)” ทำได้เฉพาะผู้ถือใบอนุญาต “ผู้ควบคุมเครื่องประมวลผลข้อมูล” เท่านั้น

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

    • ผมเคยเห็นคน IT เก่ง ๆ หลายคนที่รู้สึกแบบนั้น แต่จากประสบการณ์ของผม ฝ่าย IT ส่วนใหญ่พอทำให้ครบรายการที่สัญญากำหนด ก็ไม่ค่อยสนใจว่าจะแก้ปัญหาจริงได้หรือไม่
      ที่ทำงานเก่าเคยมีซอฟต์แวร์คล้าย CrowdStrike ถูกติดตั้งลงบนเวิร์กสเตชันของผมช่วงสุดสัปดาห์ พอกลับมาเจอก็พบว่า เวลา compile ช้าลง 20%
      ตอนนั้นผมกำลังวัดเรื่องนี้อยู่เลยมีค่าที่วัดไว้หลายสิบชุด และใช้การติดตาม ETL แสดงให้เห็นว่าซอฟต์แวร์นั้นเป็นสาเหตุ แต่ IT ไม่ยอมรับ เพราะในสัญญาของผู้ให้บริการระบุว่าจะไม่มีผลกระทบด้านประสิทธิภาพกับ workload ของเรา
    • ฝ่าย IT ส่วนใหญ่คงไม่ได้คาดการณ์เรื่องนี้ไว้ และก็สมเหตุสมผลที่ไม่ได้วางกลยุทธ์ความปลอดภัยทั้งหมดตามความเป็นไปได้นั้น ผมไม่รู้ว่าเรื่องเล่าแบบนี้มาจากไหน
      Falcon ให้ ประโยชน์ด้านความปลอดภัย ที่เป็นรูปธรรมและแท้จริงแก่ลูกค้า และยังให้ประโยชน์นั้นอยู่ แต่นั่นไม่ได้หมายความว่าจะกำจัดความเสี่ยงทั้งหมด หรือไม่สร้างความเสี่ยงของตัวเองขึ้นมา
      เช่นเดียวกับปัญหาทางวิศวกรรมทั้งหมด มันคือเกมของ การแลกเปลี่ยน อย่างแท้จริง และคนที่นี่ก็ไม่น่าจะไม่คุ้นกับเรื่องนี้
      จู่ ๆ HN ก็เต็มไปด้วยผู้เชี่ยวชาญด้านความปลอดภัยที่เต็มไปด้วย hindsight bias และ recency bias อธิบายว่าบริษัทต่าง ๆ จะหลบกระสุนลูกนี้ได้อย่างไร แต่ไม่พิจารณากระสุนจริง ๆ ที่บริษัทเหล่านั้นกำลังหลบอยู่ตั้งแต่แรกด้วยการใช้ Falcon

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

    • ผมไม่ได้มองเลยว่าผู้บริหารของ CrowdStrike มองสถานการณ์นี้เป็นเรื่องเล็กน้อย ตรงกันข้าม สุนทรพจน์นั้นดูเหมือนเป็นการรับเรื่องนี้อย่างจริงจัง ยอมรับว่าเป็นความผิดพลาดครั้งใหญ่ และจะรับถ้วยรางวัลนั้นไว้เป็น สัญลักษณ์แห่งความอับอาย รวมถึงเป็นเรื่องเตือนใจสำหรับพนักงาน CrowdStrike ในอนาคต
      ผมคิดว่าการที่ผู้บริหารคนนั้นยอมรับรางวัลนี้เป็นการกระทำที่มีระดับจริง ๆ แน่นอนว่าการพูดแบบนั้นไม่ได้หมายความว่า CrowdStrike จะพ้นจากความรับผิดชอบต่อเหตุการณ์นี้หรือความรับผิดในการชดใช้ใด ๆ เลย
    • ถ้าทำเป็นเสื้อยืดก็คงตลกได้
      When I use
      REGEXP
      I use it in my
      KERNEL CODE
      โศกนาฏกรรมกับคอเมดี้เป็นสองด้านของเหรียญเดียวกัน

  • ผ่าน xcancel: https://xcancel.com/singe/status/1822324795645575263

  • ปัญหาความปลอดภัยคอมพิวเตอร์ปรากฏขึ้นตั้งแต่สมัยสงครามเวียดนามแล้ว และสหรัฐฯ ก็เคยลงมือค้นหาโมเดลความปลอดภัยคอมพิวเตอร์ที่ได้ผลจริง แต่ตอนนี้เราอยู่ในสังคมที่แทบจะ ลบเรื่องนั้นออกจากความทรงจำ ไปแล้ว
    ทำไมต้องมีสแกนเนอร์ทำงานตลอด 24 ชั่วโมง 365 วันอยู่เหนือทุกอย่างที่คอมพิวเตอร์กำลังจะรัน?
    ทำไมระบบปฏิบัติการต้องพึ่งพา สิทธิ์รอบนอก?
    การโทษ CrowdStrike มีแต่จะเบี่ยงสายตาออกจากความล้มเหลวเชิงออกแบบพื้นฐานในระบบปฏิบัติการอย่าง Linux, MacOS, Windows ฯลฯ ที่เรามองข้ามกันทุกวัน

  • ยังมีคนโทษ Microsoft อยู่ แต่ก็ไม่ใช่ว่าจะเป็นไปไม่ได้ที่จะรันโค้ดที่ถูกอัปเดตอยู่นอกเคอร์เนล และใช้ โค้ดโหมดเคอร์เนล เฉพาะกับการสังเกตและการกระทำ ไม่ใช่กับตรรกะ

  • ผมทำงานด้าน IT และเป็นคนโชคร้ายที่ดันอยู่เวร on-call พอดีตอนที่ Clown Strike ทำให้อินฟราส่วนใหญ่ล่ม
    โดยส่วนตัวแล้ว การที่ผมยืนกรานไม่ใช้เรื่องไร้สาระแบบคลาวด์ น่าจะทำให้กู้คืนได้ภายในไม่กี่ชั่วโมงแทนที่จะเป็นหลายวัน
    ผมค่อนข้างกังวลว่าอีกไม่นานคงต้องรับมือกับ เหตุขัดข้องครั้งใหญ่บนคลาวด์ อีก เพราะคนอย่างผู้อำนวยการ IT ไม่มองว่านี่เป็นปัญหา และไม่ทำอะไรเลยเพื่อป้องกันเรื่องไร้สาระแบบนี้
    ผมพูดซ้ำจนเบื่อว่า “มีแต่คนโง่เท่านั้นที่พึ่งพาคอมพิวเตอร์ของคนอื่น” และผมเห็นด้วยกับประโยคนั้น 100%

    • มันแปลกที่มีผู้จัดการหรือผู้บริหารที่เข้าใจว่า single point of failure ในอินฟราภายในเป็นเรื่องแย่ แต่กลับมองว่าการที่ผลิตภัณฑ์หรือบริการของผู้ให้บริการภายนอกกลายเป็น single point of failure นั้นไม่เป็นไร
      ดูเหมือนพอทำสัญญาและจ่ายเงินแล้ว ก็คิดว่ามันถูกสร้างและดูแลโดยยอดมนุษย์ที่ไม่ทำผิดพลาด ต่างจากวิศวกรภายในบริษัท ผมไม่เข้าใจความเชื่อใจผิด ๆ แบบนี้เลย
    • เห็นด้วย 100% แถมยังน่าตกใจที่เห็นคนจ่ายเงินมหาศาลให้บริการคลาวด์อย่าง Azure VD
      แค่ใช้งบคลาวด์รายปีบางส่วน บริษัทก็สามารถสร้าง อินฟราที่เสถียรมากและใช้งานแบบออฟไลน์ได้ ด้วยตัวเองแล้ว
    • น้ำเสียงฟังดูก้าวร้าวมาก ต่อให้พูดถูก ผมก็คงไม่อยากทำงานด้วย
      ถ้าไม่พูดก้าวร้าวขนาดนั้น อาจสื่อสารประเด็นได้ดีกว่านี้ก็ได้
    • ถ้า CTO โง่ ๆ ไปรับคำแนะนำจากงาน CTO summit, ที่ปรึกษาซึ่งแรงจูงใจบิดเบี้ยว และงานประชุมสุ่มสารพัด ก็ทำอะไรได้ไม่มากนัก

  • รายชื่อผู้ชนะ Pwnie Award ก่อนหน้านี้เพื่อเปรียบเทียบ: https://en.wikipedia.org/wiki/Pwnie_Awards

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

  • อยากรู้จริง ๆ ว่าหลังจากความวุ่นวายครั้งนี้ CEO กับ CTO ยังรักษาตำแหน่งไว้ได้อย่างไร

  • 911 ใช้งานไม่ได้ในหลายเมือง และการไหลของงานในโรงพยาบาลช้าลงจนแทบหยุด แต่ยังมีเวลาไป Defcon แล้วเล่นมุกกันเหรอ?

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