คำแปลนี้สร้างโดยเครื่องและอยู่ระหว่างการตรวจสอบ เปลี่ยนเป็นภาษาอังกฤษ
แดชบอร์ด

กรณีการใช้งาน

ความสำเร็จมีหน้าตาอย่างไร ในสาม slice ของ traffic การใช้งานจริง

ตัวเลขใน ส่วนผลลัพธ์ ของเรา — การลด chargeback ค่ามัธยฐานประมาณ 47% อัตราผลบวกลวงต่ำกว่าครึ่งเปอร์เซ็นต์ การยืนยันตอบกลับในไม่กี่มิลลิวินาที — มาจากการผสานระบบอย่างด้านล่าง กรณีที่นี่เป็นการประกอบแบบไม่ระบุตัวตน รูปแบบเป็นของจริง

Marketplace

ปัญหา: วงจรบัญชีปลอมที่สร้างบัญชีหลายสิบบัญชีเพื่อ review-bomb จัดการอันดับผู้ขาย หรือใช้โปรโมชัน welcome-bonus ในทางที่ผิด

สัญญาณ: สิบสองบัญชีที่สร้างภายในสองชั่วโมง ทั้งหมดจากการเชื่อมต่อที่ต่างกัน — แต่มีสัญญาณเบราว์เซอร์และการแก้ไขที่ชี้ไปยังกลุ่ม automation เดียว

สัญญาณสะสมอย่างไร

การสมัครสมาชิกเดียวจากการเชื่อมต่อที่บ้านบนเบราว์เซอร์จริงไม่มีอะไรน่าสังเกต สิบสองการสมัครจากสิบสองการเชื่อมต่อที่บ้านที่ต่างกัน บนสิ่งที่ดูเหมือนเป็นเบราว์เซอร์อัตโนมัติเดียวกันที่มีลายเซ็นการแก้ไขเดียวกัน คือวงจรบัญชีปลอม

หมวดหมู่ที่ทำงานร่วมกันที่นี่:

  • Automation และบอท (01) — ลายเซ็น headless browser บนทุกบัญชี
  • การแก้ไข Fingerprint (02) — drawing test ที่ไม่ตรงกับเวอร์ชันเบราว์เซอร์ที่อ้างไว้
  • การใช้โครงสร้างพื้นฐานในทางที่ผิด (03) — residential proxy ที่ขายโดยผู้ดำเนินการฉ้อโกงที่รู้จัก
  • ความผิดปกติเชิงพฤติกรรม (06) — ฟอร์มสมัครสมาชิกที่กรอกในรูปแบบเหมือนกัน ด้วย timing เดียวกัน

ไม่มีหมวดหมู่เดียวที่จะ flag วงจรนี้ได้ คะแนนความเสี่ยงที่รวมกันทำได้

นโยบาย

marketplace บล็อกที่ tier สูงสุด — วงจร ไม่ใช่ลูกค้า — และ step up ไปยังการยืนยันทางโทรศัพท์เมื่อความเสี่ยงสูงและ confidence แน่นหนา ทุกอย่างอื่นผ่านได้โดยไม่ถูกสัมผัส ในทางปฏิบัติ policy ทั้งหมดเป็นโค้ดไม่กี่บรรทัดที่อ่านระดับความเสี่ยงที่ Noxtica ส่งคืน

ผลลัพธ์

การสมัครปลอมลดลงประมาณ 70% ภายในหนึ่งเดือนหลังการผสานระบบ อัตราการแปลงการสมัครของลูกค้าจริงไม่เปลี่ยนแปลง

บริการทางการเงิน

ปัญหา: การฉ้อโกง card-not-present โดยเฉพาะการโจมตี account-takeover ที่ผู้โจมตีมีรายละเอียดบัตรแต่ไม่มีอุปกรณ์ที่ผู้ถือบัตรรู้จัก

สัญญาณ: เซสชันที่โปรไฟล์ไม่ตรงกับอุปกรณ์ที่ผู้ถือบัตรรู้จัก การตอบสนองคือ step-up verification ไม่ใช่การบล็อกทันที ลูกค้าจริงไม่เจอแรงเสียดทาน วงจรฉ้อโกงเจอการตรวจสอบเพิ่มเติมในทุก transaction

สัญญาณสะสมอย่างไร

การฉ้อโกง card-not-present เพิ่มขึ้นโดยใช้รายละเอียดบัตรจริงที่ขโมยมาบนอุปกรณ์ที่ผู้โจมตีควบคุม อุปกรณ์คือตัวแยกแยะ เราติดตามโปรไฟล์ต่อลูกค้า เมื่อ transaction เข้ามาจากโปรไฟล์ที่เราไม่เคยเห็นสำหรับลูกค้ารายนั้น เรา flag มัน

หมวดหมู่ที่ทำงานร่วมกันที่นี่:

  • การตรวจสอบฮาร์ดแวร์ (05) — อุปกรณ์ใหม่อาจมีลายเซ็น graphics, audio หรือ memory ที่ต่างกัน
  • การใช้โครงสร้างพื้นฐานในทางที่ผิด (03) — วงจรฉ้อโกงมักรันจาก datacenter แม้ใช้ residential proxy ด้านหน้า
  • ความผิดปกติเชิงพฤติกรรม (06) — timing ของ checkout ที่ไม่ตรงกับประวัติของผู้ถือบัตร

สัญญาณ new-device เพียงอย่างเดียวไม่ได้เป็นอันตราย — ลูกค้าซื้อโทรศัพท์ เปลี่ยนแล็ปท็อป ติดตั้งระบบปฏิบัติการใหม่ เราถ่วงน้ำหนักมันกับหมวดหมู่อื่นเพื่อแยก “ลูกค้าบนอุปกรณ์ใหม่” ออกจาก “ผู้โจมตีที่มีรายละเอียดบัตรที่ขโมยมา”

นโยบาย

ลูกค้าที่กลับมาบนอุปกรณ์ที่รู้จัก ต่ำกว่า tier สูงสุด ผ่านได้ตรงโดยไม่มีแรงเสียดทาน เมื่อความเสี่ยงสูง — หรืออุปกรณ์ใหม่ปรากฏบน transaction ที่มีขนาดใหญ่ผิดปกติ — เซสชันจะได้รับ step-up verification แทนการบล็อกทันที การเอนเอียงเสมอคือให้ลูกค้าจริงทำการซื้อให้เสร็จสมบูรณ์

ผลลัพธ์

การสูญเสียจาก chargeback ลดลงประมาณ 45 ถึง 50% ภายในสามเดือน Step-up verification ถูกพบโดยเพียงส่วนเล็กๆ ของ transaction และส่วนใหญ่ทำเสร็จสำเร็จ — ลูกค้าจริงผ่าน challenge

แพลตฟอร์มที่อ่อนไหวต่อตัวตน

ปัญหา: แพลตฟอร์ม passwordless และ single-sign-on จำเป็นต้องยืนยันว่าตัวตนที่คลิก login link เป็นตัวตนเดียวกับที่ขอมัน ชุด phishing และบริการ link-relay ทำลายสมมติฐานนั้น

สัญญาณ: link ที่คลิกจากโปรไฟล์ที่ต่างจากโปรไฟล์ที่ขอมันจะกระตุ้นขั้นตอนการยืนยันเพิ่มเติม ชุด phishing และบริการ link-relay ถูกจับที่ด่านนี้

สัญญาณสะสมอย่างไร

เมื่อมีการขอ login link เราบันทึกโปรไฟล์ที่ขอ เมื่อ link ถูกคลิก เราตรวจสอบโปรไฟล์ซ้ำและเปรียบเทียบ หากตรงกัน — เบราว์เซอร์เดียวกัน อุปกรณ์เดียวกัน — link จะยืนยันตัวตนอัตโนมัติ หากไม่ตรง เราปฏิบัติต่อการคลิกเป็นเซสชันที่ต่างกันและต้องการขั้นตอนการยืนยันเพิ่มเติม

หมวดหมู่ที่ทำงานร่วมกันที่นี่:

  • การแก้ไข Fingerprint (02) — ชุด phishing มักรันเบราว์เซอร์ headless ที่โปรไฟล์ไม่ตรงกับอุปกรณ์จริงของผู้ใช้
  • ความผิดปกติเชิงพฤติกรรม (06) — เวลาระหว่างการขอและการคลิก แหล่งที่มาของ traffic และวิธีที่เซสชันเปลี่ยนล้วนสำคัญ
  • การใช้โครงสร้างพื้นฐานในทางที่ผิด (03) — บริการ link-relay มักรันจากโครงสร้างพื้นฐาน cloud

นโยบาย

หากอุปกรณ์ที่คลิกตรงกับอุปกรณ์ที่ขอ link login link ทำงานอัตโนมัติ หากไม่ตรง แพลตฟอร์มต้องการ second factor ก่อนให้เซสชันผ่าน การตรวจสอบการจับคู่เป็นการเปรียบเทียบง่ายๆ กับโปรไฟล์ที่บันทึกไว้เมื่อ link ออก

ผลลัพธ์

อัตราความสำเร็จของ phishing ต่อแคมเปญ login-link ลดลงอย่างมาก — โดยทั่วไปลดการโจมตี credential-relay ที่สำเร็จได้มากกว่า 90% ผู้ใช้จริงที่เปลี่ยนอุปกรณ์อย่างถูกต้องจะเห็นขั้นตอนการยืนยันเพิ่มเติมหนึ่งขั้น จากนั้นจะถูกเพิ่มเข้าใน trusted-device list สำหรับ link ในอนาคต

รูปแบบ: เมื่อใดควรบล็อก เมื่อใดควร challenge

ทั่วทั้งสามกรณีการใช้งาน โครงสร้าง policy เหมือนกัน:

  1. ความเสี่ยง Critical — block พร้อม logging เซสชันเหล่านี้ไม่คุ้มกับต้นทุนของการ challenge
  2. ความเสี่ยง High — challenge: step-up verification, second factor หรือ manual review ลูกค้าจริงผ่าน บอทไม่ผ่าน
  3. ความเสี่ยง Medium — observe บันทึกเซสชันและนำเสนอใน dashboard แต่ไม่เพิ่มแรงเสียดทาน
  4. ความเสี่ยง Low หรือ minimal — allow traffic ส่วนใหญ่

สี่การกระทำเหล่านี้จับคู่กับโมเดลความเสี่ยงห้าระดับ: สอง tier ต่ำสุดทั้งคู่ยุบรวมเป็น “allow” สำหรับเกือบทุกคน แต่การแยกไว้มีประโยชน์ใน dashboard สำหรับการเข้าใจว่าประชากรของคุณอยู่ตรงไหน

อ่านเพิ่มเติม