- มีการเปิดโปงว่า แพลตฟอร์ม Delve ถูกใช้งานเป็น ‘ระบบที่ทำให้ดูเหมือนปฏิบัติตามข้อกำหนด’ โดยไม่มีมาตรการควบคุมความปลอดภัยจริง
- จากการตรวจสอบภายในและการวิเคราะห์สเปรดชีตที่รั่วไหล พบว่า รายงานตรวจประเมิน การทดสอบ และข้อสรุปถูกสร้างอัตโนมัติโดย Delve และหน่วยรับรองในอินเดียเป็นผู้ ลงนามแบบพิธีการ
- ลูกค้า นำหลักฐานปลอม บันทึกการประชุมเท็จ และเอกสารนโยบายที่ถูกกรอกอัตโนมัติ ไปใช้เพื่อแสดงราวกับว่าได้รับการรับรอง SOC 2·ISO 27001·HIPAA·GDPR
- Delve โฆษณาว่าเป็น ระบบอัตโนมัติที่ขับเคลื่อนด้วย AI แต่ในความเป็นจริงเป็น ระบบฟอร์มที่เน้นการกรอกข้อมูลด้วยมือและอัปโหลดภาพหน้าจอ และฟังก์ชัน ‘integration’ ส่วนใหญ่ใช้งานไม่ได้
- ผลคือมีบริษัทหลายร้อยแห่ง ประกาศสถานะความปลอดภัยอันเป็นเท็จต่อภายนอก และเผชิญความเสี่ยงจากการละเมิด HIPAA·GDPR รวมถึงความรับผิดทางกฎหมาย
ปัญหาเชิงโครงสร้างของ Delve และการเปิดโปงหลัก
- Delve ถูกโปรโมตในฐานะแพลตฟอร์ม compliance automation สำหรับ SOC 2, ISO 27001, HIPAA, GDPR ฯลฯ แต่ในความเป็นจริงกลับ ละเมิดหลักความเป็นอิสระของผู้ตรวจประเมิน และเขียนข้อสรุปการตรวจเอง
- ในร่างรายงานตรวจประเมินมี ข้อสรุปและขั้นตอนการทดสอบที่ Delve เขียนไว้ล่วงหน้า อยู่แล้ว โดยลูกค้าเพียงกรอกชื่อ ลายเซ็น และไดอะแกรมเท่านั้น
- รายงานทั้งหมดใช้โครงสร้างประโยคและแม้แต่คำพิมพ์ผิดแบบเดียวกัน โดย มากกว่า 99% จาก 575 ฉบับมีข้อความเดียวกัน
- ใน Google Spreadsheet ที่รั่วไหลมี ลิงก์รายงานตรวจประเมินของลูกค้าหลายร้อยราย รวมถึงข้อมูลอ่อนไหวอย่างลายเซ็นส่วนบุคคลและไดอะแกรมระบบ
- CEO ของ Delve อ้างว่านี่คือ “อีเมลปลอมที่ AI สร้างขึ้น” แต่พบเอกสารจริงได้จากคลังเอกสารสาธารณะ
การละเมิดความเป็นอิสระของการตรวจประเมินและระบบตรวจปลอม
- Delve ทำหน้าที่เป็นผู้ตรวจประเมินโดยตรง ซึ่งละเมิดข้อกำหนดของ AICPA
- ข้อสรุปการตรวจถูกเขียนไว้ล่วงหน้า ทำให้ไม่สามารถตรวจสอบอย่างอิสระได้
- หน่วยรับรองในอินเดียอย่าง Accorp, Gradient, BQC, Glocert ลงนามในรายงานผ่าน นิติบุคคลเปลือกในสหรัฐฯ
- บางรายงานมี หมายเลขใบอนุญาตผู้ตรวจประเมินที่ไม่ถูกต้อง สะท้อนร่องรอยการคัดลอกเทมเพลตเดียวกัน
- Jayshree Dutta ซึ่งถูกระบุว่าเป็นผู้รับผิดชอบการตรวจ ไม่ใช่ CPA ในสหรัฐฯ และยืนยันได้ว่าเกี่ยวข้องกับบริษัทอินเดีย CyberTryZub และ BQC
ความเป็นเท็จของผลิตภัณฑ์และกระบวนการ
- ‘ระบบอัตโนมัติด้วย AI’ ของ Delve เป็นเพียง ระบบฟอร์มแบบแมนนวลที่แทบไม่มีความสามารถ AI จริง
- ‘integration’ ส่วนใหญ่ ขอเพียงอัปโหลดภาพหน้าจอโดยไม่มีกระบวนการยืนยันตัวตน
- นโยบาย การประเมินความเสี่ยง และการจำลองความปลอดภัย ถูกจัดทำเป็น เทมเพลตที่ใส่ค่าเริ่มต้นไว้แล้ว ซึ่งเสร็จได้เพียงแค่คลิก
- โมดูล Pathways ถูก Delve อ้างว่าพัฒนาขึ้นเอง แต่พบว่า นำโอเพนซอร์ส SimStudio มาใช้โดยไม่ได้รับอนุญาต
- ลูกค้าต้อง ยอมรับบันทึกการประชุมปลอม ผลการทดสอบความปลอดภัยปลอม และเอกสารนโยบายปลอม ไม่เช่นนั้นจะต้องทำงานส่วนใหญ่ด้วยตนเอง
รายงานปลอมและการบิดเบือน Trust Page
- Trust Page ของ Delve แสดงมาตรการควบคุมความปลอดภัยที่ยังไม่ได้ใช้งานจริงว่า ‘เสร็จสมบูรณ์’
- จากลูกค้า SOC 2 จำนวน 322 ราย มี 321 รายที่ใช้ รายการควบคุม 51 ข้อชุดเดียวกัน
- มาตรการความปลอดภัยอย่าง MDM การตรวจจับการบุกรุก การสำรองข้อมูล และการลบข้อมูล ซึ่ง ไม่มีอยู่จริง ถูกแสดงอัตโนมัติว่าได้ดำเนินการแล้ว
- ในรายงาน SOC 2 Type II มีการระบุว่าผ่านเกณฑ์ทั้งหมดทั้ง “security·availability·confidentiality·privacy” แต่การทดสอบจริงมีเพียง หัวข้อความปลอดภัยข้อเดียว
- ทุกรายงานลงท้ายด้วยข้อความเดียวกันว่า “No exceptions noted”
ความเสี่ยงด้านกฎระเบียบและกฎหมาย
- กระบวนการอันเป็นเท็จของ Delve ทำให้ลูกค้าอยู่ในสถานะ ละเมิด GDPR·HIPAA
- การละเมิด HIPAA อาจนำไปสู่โทษทางอาญา ส่วนการละเมิด GDPR อาจถูกปรับ สูงสุด 4% ของรายได้ทั่วโลก
- ยังมีบริษัทรวมอยู่ด้วยที่ประมวลผลข้อมูลด้านการแพทย์และกลาโหม จึงก่อให้เกิด ความเสี่ยงระดับความมั่นคงแห่งชาติ
- ลูกค้าของ Delve ได้ ยื่นรายงานรับรองอันเป็นเท็จต่อบุคคลภายนอกโดยไม่รู้ตัว และอาจต้องรับผิดทั้งตามสัญญาและด้านชื่อเสียง
บทสรุปและคำแนะนำ
- Delve เป็น ตัวอย่างของการทำอุตสาหกรรมให้กับโครงสร้าง ‘compliance automation ปลอม’ ที่ผลักลูกค้าเข้าสู่ความเสี่ยงทางกฎหมาย
- ลูกค้าปัจจุบันควร บันทึกการสื่อสารทั้งหมดกับ Delve เป็นลายลักษณ์อักษร และสอบถามให้ชัดเจนเรื่อง การสร้างรายงานตรวจ ความเป็นอิสระของผู้ตรวจ และขอบเขตของข้อมูลรั่วไหล
- “กระบวนการสร้างความน่าเชื่อถือด้วย AI” ที่ Delve อ้างนั้นเป็นเพียง ระบบสร้างเอกสารเชิงพิธีการ และ ไม่มีความสามารถตรวจสอบความปลอดภัยที่เป็นสาระจริง
- เหตุการณ์นี้สะท้อน การพังทลายของความน่าเชื่อถือในตลาด compliance automation และย้ำความสำคัญของ การตรวจประเมินที่เป็นอิสระและมาตรการควบคุมความปลอดภัยที่แท้จริง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สตาร์ตอัปจำนวนมากมีลักษณะเด่นคือขับเคลื่อนได้เร็วด้วยทีมขนาดเล็ก
ถ้าสร้างผลิตภัณฑ์ที่ดี บริษัทใหญ่ก็อยากสมัครใช้งาน แต่ก็ต้องผ่านกระบวนการรับรอง
เช็กลิสต์มีประโยชน์ แต่ถูกออกแบบมาให้สอดคล้องกับระบบราชการแบบยุโรปมากเกินไป
คุณจะถูกถามอะไรทำนองว่า “risk register ของบริษัทที่มีพนักงาน 7 คนอยู่ที่ไหน?” แล้วสุดท้ายก็ต้องหมกมุ่นกับงานเอกสารแทนงานหลัก
กลายเป็นว่าต้องสร้างเอกสารที่ในความเป็นจริงไม่มีใครอ่าน แต่งกระบวนการที่ไม่มีอยู่จริงขึ้นมา และแปลบริษัทที่คล่องตัวให้กลายเป็นภาษาขององค์กรยักษ์
เราต้องการมาตรฐานที่ใช้งานได้จริงและได้สัดส่วนสำหรับทีมเล็ก
บริษัทของฉันเป็น Fortune 500 แต่กระบวนการจัดซื้อซับซ้อนเกินไปจนทำให้เอา SaaS มาใช้ได้ยาก
ในขณะที่คู่แข่งมีขั้นตอนที่ยืดหยุ่นกว่าและหาผู้ขายที่ดีได้เร็วกว่า ความต่างแบบนี้สุดท้ายก็กลายเป็นความสามารถในการแข่งขัน
Level 1 ดีในฐานะพื้นฐาน และ Level 2 ก็เลือกใช้เพิ่มเติมได้ตามความเสี่ยงทางธุรกิจ
CIS Benchmarks ก็น่าดูเหมือนกัน เป็นชุดแนวปฏิบัติที่ดีสำหรับความปลอดภัยของคลาวด์, SaaS และ OS
ถ้า ‘corporate theater’ แบบนี้นำไปสู่รายได้ มันก็เป็นส่วนหนึ่งของธุรกิจเช่นกัน
ถ้าคุณไม่ส่งมอบผลิตภัณฑ์ในรูปแบบที่ลูกค้าต้องการ สุดท้ายก็จะถูกตลาดคัดออก
คนที่ควบคุมเช็กลิสต์คือคนที่ได้ประโยชน์
Compliance ไม่ได้ยากขนาดนั้น ถ้าไม่มองหาทางลัดและยอมใช้เวลาอย่างจริงจัง
ฉันคิดว่า AWS คือผู้ให้บริการ CaaS (Compliance as a Service) ในความหมายที่แท้จริง
ผ่าน AWS Artifact ลูกค้าสามารถผ่านกระบวนการรับรองที่ซับซ้อนได้ง่ายขึ้น
แน่นอนว่าซอฟต์แวร์หรือนโยบายยังเป็นความรับผิดชอบของผู้ใช้ แต่ความปลอดภัยทางกายภาพ การดูแลฮาร์ดแวร์ และการกู้คืนจากภัยพิบัติ แทบจะได้มาแบบ “ฟรี”
เพียงแต่ถ้าเทียบกับผู้ให้บริการโครงสร้างพื้นฐานแบบเรียบง่ายอย่าง Hetzner ก็จะมีส่วนต่างราคาค่อนข้างสูง
ฉันสงสัยว่าผู้ก่อตั้งวัยยี่สิบต้น ๆ จะมีโอกาสอยากแก้ปัญหาเรื่องการตรวจประเมิน complianceด้วยความหลงใหลจริง ๆ มากแค่ไหน
มันเป็นเรื่องที่น่าเบื่อเกินไปจนยากจะรู้สึกสนใจ หรือพวกเขาแค่กระโดดเข้ามาเพราะโอกาสทางธุรกิจ?
มีคำพูดกันว่าปัญหาที่ยิ่งดูธรรมดา ยิ่งทำเงิน
เหมือนบทความของ Joel Spolsky “Where there’s muck, there’s brass”
วิศวกรเก่ง ๆ วัยยี่สิบกว่ากำลังพัฒนาเครื่องมือมอนิเตอร์ Compliance Management System อยู่
พวกเขาใช้ AI เพื่อแก้ปัญหาทางธุรกิจที่มีมานานแล้ว ในฝั่งตะวันออกของสหรัฐฯ ตลาดในภาคธนาคาร พลังงาน และเฮลท์แคร์ใหญ่มาก
โชคดีที่ส่วนเทคนิคยังน่าสนใจ
จากมุมลูกค้า compliance สร้างความเจ็บปวดมาก จนแค่ทำให้มันอัตโนมัติขึ้นได้นิดหน่อยก็มีคุณค่ามหาศาลแล้ว
คือรวบรวมคนวัยยี่สิบที่ฉลาด ๆ มาระดมทุนภายใต้คำว่า “จะปฏิวัติอุตสาหกรรม”
คล้ายกับที่ที่ปรึกษา McKinsey มีอิทธิพลจากชื่อแบรนด์มากกว่าตัวงานจริง
YC ก็ดูเหมือนจะทำหน้าที่แบบนั้นเหมือนกัน
ต่อให้บทความนี้เป็นการโจมตีจากคู่แข่งจริง หลักฐานที่ยกมาก็แข็งแรงมาก
ถ้าเป็นเรื่องเท็จ ค่าเสียหายจากการหมิ่นประมาทคงแตะหลายสิบล้านดอลลาร์
ขอชื่นชมความกล้าที่กล้าเปิดโปงเรื่องนี้
น่าสนใจที่ผู้เขียนกับเครือข่ายของเขาเพิ่งออกมาตั้งคำถาม หลังจากที่การรับรองของตัวเองถูกเปิดโปงว่าใช้ไม่ได้แล้วเท่านั้น
ตอนนี้พวกเขาดูเหมือนกำลังพยายามทำตัวเป็น ‘คนดีผู้เปิดโปง Delve’
ฉันเคยผ่านกระบวนการนี้มากับตัว
ฉันคิดว่าความล้มเหลวที่แท้จริงอยู่ที่หน่วยงานรับรองซึ่งรับเงินแล้วออกใบรับรองโดยไม่ตรวจสอบ
ตัวกลางอย่าง Delve เป็นเพียงสิ่งที่ขยายความล้มเหลวนั้นให้รุนแรงขึ้น
ใครที่อยู่ในวงการต่างก็รู้ว่านี่เป็นแค่security theater
ประทับใจกับความลึกของบทความนี้มาก
เราเองก็เพิ่งพิจารณา Drata อยู่ไม่นานนี้ และตอนแรกมันก็ดูใช้ได้ทีเดียว
แต่พอเกิดเรื่องแบบนี้ขึ้นมาทีไร ก็อดสงสัยไม่ได้ว่ายังมีการหลอกลวงที่ยังไม่ถูกเปิดเผยอีกมากแค่ไหน
เป้าหมายเดียวของการทดสอบคือการค้นหาความล้มเหลว
ท่ามกลางบรรยากาศที่ทุกคนแค่ทำตามกันไป การที่มีคนออกมาชี้ปัญหาแบบเปิดเผยถือว่าสดใหม่ดี
ฉันเห็นบทความนี้บน LinkedIn แล้ว น่าสนใจมาก
ถ้าเป็นบทความที่เจาะลึกขนาดนี้ ฉันคิดว่าป่านนี้ควรขึ้นหน้าแรกของ HN แล้ว
ถ้านึกว่านี่คือเว็บไซต์ของ Y Combinator ก็มีความเป็นไปได้
บริษัทบางแห่งที่ฉันรู้จักได้ รายงาน SOC 2 Type 2 ภายใน 5 วันผ่าน Delve
พวกเขายังใช้สโลแกนการตลาดว่า “SOC 2 in days” ตรง ๆ ด้วย ฟังแล้วไม่น่าเชื่อ
Compliance เป็นสิ่งที่ไม่มีใครอยากได้ แต่ทุกคนจำเป็นต้องมี
ท้ายที่สุดมันถูกมองว่าเป็นบริการสำหรับการโยนความรับผิดชอบต่อ
ถ้าหน่วยงานกำกับถามขึ้นมา ก็แค่ยื่นใบรับรองจากที่อย่าง Delve ให้ดูแล้วจบ
ผู้ให้บริการ SaaS ควรมีความรับผิดชอบในการปกป้องข้อมูลลูกค้า
เฟรมเวิร์กด้าน compliance เป็นเครื่องมือที่ช่วยความพยายามนั้น
มันเป็นวิธีหา gap ระบุความเสี่ยง ผลักดันการปรับปรุง และอธิบายระดับความพร้อมของเราให้พาร์ตเนอร์เข้าใจ
สิ่งที่บทความบน Medium บรรยายไว้เป็นแค่การฉ้อโกง
ในฐานะผู้ก่อตั้ง ฉันอยากมอบความน่าเชื่อถือระดับสูงสุดให้ลูกค้า
Compliance ก็เหมือนกัน
คนส่วนใหญ่จ้างเราไม่ใช่เพื่อให้ระบบปลอดภัยขึ้น แต่เพื่อให้ผ่านข้อกำหนดของประกัน
สุดท้ายมันก็เป็นโครงสร้างที่พยายามโยนความรับผิดชอบออกไป
ในความเป็นจริง ผู้ก่อตั้งจำนวนมากได้ยินประโยคว่า “เราอยากซื้อผลิตภัณฑ์ของคุณ แต่ซื้อไม่ได้เพราะคุณยังไม่มีใบรับรอง” ซ้ำแล้วซ้ำเล่า
เพราะแบบนั้นพอตื่นเช้ามาก็คิดว่า “วันนี้ต้องไปเอาใบรับรอง XYZ-123 ให้ได้”
Compliance ไม่ใช่การโยนความรับผิดชอบ แต่เป็นเงื่อนไขขั้นต่ำในการพิสูจน์ความน่าเชื่อถือให้ลูกค้า
เกมที่มีคุณค่าทุกเกมล้วนมีค่าเข้าเล่น (table stakes)
การโยนมันไปให้บริษัทอื่นเป็นพฤติกรรมที่ไร้ความรับผิดชอบ