ความเสี่ยงจากบุคคลที่สามห้าประการที่เครื่องสแกนช่องโหว่ของคุณไม่สามารถมองเห็นได้

เครื่องสแกนช่องโหว่นั้นเก่งในสิ่งที่พวกเขาทำ พวกเขาจะพบว่าอินสแตนซ์ Apache ที่ไม่ได้รับการอัปเดต, บัคเก็ต S3 แบบเปิด, ชุดการเข้ารหัส TLS ที่กำหนดค่าไม่ถูกต้อง พวกเขารวบรวมข้อมูลพื้นผิวการโจมตีของคุณ จับคู่ CVE ความรุนแรงของคะแนน ยื่นตั๋ว

แต่ทั้งหมดมีจุดบอดเหมือนกัน นั่นคือสแกนโครงสร้างพื้นฐานที่คุณควบคุม ทันทีที่ความเสี่ยงเกิดขึ้นในระบบของบุคคลอื่น เครื่องสแกนของคุณก็ไม่มีอะไรต้องตรวจสอบ ไม่มีเป้าหมาย ไม่พบ ไม่มีตั๋ว

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

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

การขโมย DNS ของผู้ขายและการครอบครองโดเมนย่อย

เครื่องสแกนของคุณจะตรวจสอบบันทึก DNS ของคุณ อาจติดธง CNAME ที่ห้อยอยู่ซึ่งชี้ไปที่ทรัพยากรระบบคล��วด์ที่ยกเลิกการจัดสรร ดี. แต่ DNS ของผู้ประมวลผลการชำระเงินของคุณล่ะ? โดเมนย่อยของผู้ให้บริการข้อมูลประจำตัวของคุณ? โดเมนดึงต้นทางของ CDN ของคุณ? สิ่งเหล่านั้นไม่อยู่ในขอบเขต

การไฮแจ็ก DNS กับผู้ให้บริการที่คุณพึ่งพาจะไม่ทำให้สแกนเนอร์ของคุณสะดุดเนื่��งจากโดเมนไม่ใช่ของคุณ ผู้โจมตีเข้าควบคุม auth.vendor.com สร้างหน้าการเก็บเกี่ยวข้อมูลรับรอง และการผสานรวม SSO ของคุณจะเปลี่ยนเส้นทางผู้ใช้ไปยังหน้าดังกล่าวอย่างมีความสุข จากมุมมองของโครงสร้างพื้นฐานของคุณ ไม่มีอะไรเปลี่ยนแปลง CNAME ยังคงแก้ไขได้ การจับมือ TLS เสร็จสิ้น (ผู้โจมตีจัดเตรียมใบรับร��งผ่านการท้าทาย ACME บนโดเมนที่ถูกไฮแจ็ก) บันทึกของคุณแสดงการเปลี่ยนเส้นทางที่สำเร็จ

กรอบเวลาการตรวจจับที่นี่คือนาที ไม่ใช่วัน หากคุณไม่ได้ตรวจสอบห่วงโซ่การแก้ปัญหา DNS สำหรับอุปกรณ์ปลายทางที่สำคัญของบริษัทภายนอก ซึ่งรวมถึงเป้าหมาย CNAME การมอบหมาย NS และบันทึก SOA คุณจะต้องอาศัยผู้ขายทั้งหมดในการแจ้งให้ทราบก่อน

สิ่งที่ใช้งานได้จริง: การตรวจสอบบันทึก DNS อย่างต่อเนื่องโดยเทียบกับพื้นฐานที่ทราบดีสำหรับโดเมนบุคคลที่สามทุกรายการที่แอปพลิเคชันของคุณรวมเข้าด้วยกัน เมื่อ auth.vendor.com เปลี่ยนเป็น IP ใหม่กะทันหันหรือบันทึก NS เปลี่ยนไป นั่นเป็นสัญญาณที่คุ้มค่าที่จะปลุกใครสักคน ประเภทบันทึกที่สำคัญที่สุดคือ A/AAAA, เป้าหมาย CNAME, การมอบหมาย NS และอนุกรม SOA การเปลี่ยนแปลงที่ไม่คาดคิดใดๆ ในสิ่งเหล่านี้ควรค่าแก่การแจ้งเตือน

ใบรับรองบุคคลที่สามหมดอายุแบบเรียงซ้อนในห่วงโซ่การตรวจสอบของคุณ

เครื่องสแกนของคุณตรวจสอบใบรับรองของคุณ รู้ว่าเมื่อใด api.yourcompany.com จ��หมดอายุใน 30 วัน และยื่นตั๋วต่ออายุ แต่ใบรับรองใน login.identityprovider.com? บน api.Paymentgateway.io? บนโหนด Edge CDN ที่ให้บริการชุด JavaScript ที่ติดต่อกับลูกค้าของคุณหรือไม่

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

สิ่งนี้เกิดขึ้นกับผู้ให้บริการข้อมูลระบุตัวตนรายใหญ่ในปี 2024 ใบรับรองระดับกลางของผู้ให้บริการจะหมดอายุในวันเสาร์ แอปพลิเคชัน SaaS แบบดาวน์สตรีมทุกรายการที่ใช้โฟลว์ OIDC เริ่มส่งคืน 502 ให้กับผู้ใช้ปลายทาง เครื่องสแกนของผู้จำหน่าย SaaS แสดงเป็นสีเขียว ใบรับรองของพวกเขาเองก็โอเค เครื่องสแกนไม่มีแนวคิดเรื่อง “ใบรับรองที่อยู่อีกด้านหนึ่งของการโทร HTTPS ของฉันไปยัง IDP” ทีมตอบสนองต่อเหตุการณ์ใช้เวลาหลายชั่วโมงในการติดตาม 502 ผ่านโหลดบาลานเซอร์และโค้ดแอปพลิเคชันของตนเอง ก่อนที่จะมีคนคิดที่จะตรวจสอบห่วงโซ่ใบรับรองอัปสตรีม

การแก้ไขคือการตรวจสอบการหมดอายุของใบรับรองสำหรับตำแหน่งข้อมูล TLS ทุกจุดในห่วงโซ่การพึ่งพาของคุณ ไม่ใช่แค่ของคุณเอง ตรวจสอบลีฟใบรับรอง ตัวกลาง และรูท แจ้งเตือนที่ 14 วัน ไม่ใช่ 7 วัน และติดตามการหมดอายุของ CA ระดับกลางแยกกัน เนื่องจากนั่นคือสิ่งที่ผู้ขายลืมไปเอง

การลดระดับของผู้ให้บริการการชำระเงินและการรับรองความถูกต้องที่ส่งคืน 200 OK

อันนี้บอบบางและมีราคาแพง

การตรวจสอบสภาพพร้อมใช้งานของคุณส่งคำขอไปที่ api.Paymentprovider.com/v1/health พวกเขาได้คืน 200 กรีน แต่เบื้องหลังจุดสิ้นสุดด้านสุขภาพนั้น คิวการประมวลผลธุรกรรมของผู้ให้บริการจะถูกสำรองข้อมูลไว้ 40 วินาที การเรียกเก็บเงินจริงกำลังจะหมดเวลา ขั้นตอนการชำระเงินของคุณใช้งานได้ในทางเทคนิค โดยจะส่งคำขอ ได้รับการตอบกลับ (ในท้ายที่สุด) แ��ะการตอบกลับแจ้งว่า "รอดำเนินการ" เครื่องสแกนของคุณมองเห็น 200 จอภาพสังเคราะห์ของคุณมองเห็น 200 ผู้ใช้ของคุณเห็นวงล้อหมุนเป็นเวลา 45 วินาที และละทิ้งการซื้อ

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

การตรวจจับสิ่งนี้จำเป็นต้องมีการวัดเวลาตอบสนองและซีแมนทิกส์เนื้อหาการตอบสนองต่อจุดสิ้นสุดของบุคคลที่สามภายใต้เงื่อนไขจริง ไม่ใช่ "พร้อมใช้งาน" แต่ "มีประสิทธิภาพภายในขอบเขตที่แอปพลิเคชันของฉันยอมรับหรือไม่" หาก API การชำระเงินของคุณตอบสนองในอดีตใน 400 มิลลิวินาที และปัจจุบันใช้เวลา 12 วินาที นั่นถือเป็นเหตุการณ์ในการปฏิบัติงาน ไม่ว่ารหัสสถานะจะเป็น 200 หรือไม่ก็ตาม

เหตุการณ์ที่หน้าสถานะผู้ขาย SOC ของคุณไม่เคยอ่าน

ผู้จำหน่าย SaaS รายใหญ่ทุกรายเผยแพร่หน้าสถานะ AWS มีหนึ่งรายการ อ็อกต้าก็มีอันหนึ่ง Cloudflare, Stripe, Datadog, PagerDuty พวกเขาโพสต์เหตุการณ์ ทำเครื่องหมายส่วนประกอบที่เสื่อมโทรม และ (ในท้ายที่สุด) เผย���พร่การชันสูตรพลิกศพ

แทบจะไม่มี SOC ใดที่มีสิ่งเหล่านี้ในลูปการตรวจสอบ

ข้อมูลนี้เป็นข้อมูลสาธารณะ สามารถอ่านได้ด้วยเครื่อง (ส่วนใหญ่เปิดเผยฟีด JSON หรือ RSS) และเกี่ยวข้องโดยตรงกับระดับความเสี่ยงของสภาพแวดล้อมของคุณ หากผู้จำหน่ายของผู้จัดส่งบันทึกของคุณโพสต์ว่า “ไ��ป์ไลน์นำเข้าลดลงในสหรัฐฯ-ตะวันออก” นั่นจะอธิบายช่องว่างใน SIEM ของคุณ หากผู้ให้บริการรับรองความถูกต้องของคุณโพสต์ “อัตราข้อผิดพลาดที่เพิ่มขึ้นใน /ให้สิทธิ์ตำแหน่งข้อมูล” นั่นเป็นสาเหตุหลักของการแจ้งเตือนของคุณที่เพิ่มขึ้นอย่างรวดเร็วถึง 4xx

ช่องว่างเป็นเรื่องขององค์กร ไม่ใช่ทางเทคนิค ทีมรักษาความปลอดภัยไม่ดูหน้าสถานะเพราะมันให้ความรู้สึกเหมือนเป็นข้อกังวลในการปฏิบัติงาน ทีมปฏิบัติการอาจดูพวกเขาเพื่อหาผู้ให้บริการชั้นนำ 2-3 ราย แต่ไม่ใช่แบบหางยาว ผลลัพธ์: SOC ของคุณใช้เวลา 30 นาทีในการตรวจสอบช่องว่างบันทึกที่ผู้จำหน่ายได้ประกาศไว้ 20 นาทีก่อนหน้านี้ เมื่อคุณสังเกตเห็น

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

งานรักษาความปลอดภัยตามกำหนดการที่ล้มเหลวโดยไม่เกิดเหตุการณ์กับปลายทางของผู้ให้บริการ

เอเจนต์สำรองข้อมูลของคุณจะพุชสแน็ปช็อตที่เข้ารหัสไปยังจุดสิ้นสุดการจัดเก็บข้อมูลบนคลาวด์ทุกๆ 6 ชั่วโมง ผู้จัดส่งบันทึกของคุณจะส่งต่อไปยัง API การนำเข้าของผู้จำหน่าย SIEM เครื่องส���กนช่องโหว่ของคุณจะรายงานการค้นพบไปยังคอนโซล SaaS ส่วนกลาง บอตการต่ออายุใบรับรองของคุณจะเรียก API ของผู้ให้บริการ ACME

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

ผลกระทบด้านความปลอดภัยจะเพิ่มขึ้นเมื่อเวลาผ่านไป พลาดหน้าต่างสำรองไปหนึ่งหน้าต่างและคุณอาจจะสบายดี พลาดไปหนึ่งสัปดาห์เนื่องจากผู้ให้บริการพื้นที่จัดเก็บข้อมูลเลิกใช้เวอร์ชัน API อย่างเงียบๆ และคำขอของตัวแทนของคุณเริ่มส่งคืน 403 ใช่หรือไม่ ตอนนี้ RPO ของคุณใช้งานไม่ได้และไม่มีใครรู้จนกว่าจะมีการทดสอบการคืนค่า (หากคุณเรียกใช้การทดสอบการคืนค่า) ท่าทีการปฏิบัติตามข้อกำหนดของคุณถือว่ามีการสำรองข้อมูลอย่างต่อเนื่อง ความจริงก็คือช่องว่างระยะเวลาหนึ่งสัปดา��์ที่ปรากฏเฉพาะในระหว่างการตรวจสอบ หรือที่แย่กว่านั้นคือในระหว่างสถานการณ์การกู้คืนที่เกิดขึ้นจริง

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

การดำเนิน��ารติดตามความเสี่ยงของบุคคลที่สาม

รูปแบบของความเสี่ยงทั้งห้านั้นเหมือนกัน: เครื่องสแกนของคุณไม่พบสิ่งที่ไม่สามารถเข้าถึงได้ และไม่สามารถเข้าถึงระบบที่คุณไม่ได้เป็นเจ้าของ

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

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

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

ช่องว่างนั้นมีโครงสร้าง ไม่ใช่เหตุบังเอิญ

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

แต่พื้นที่ความเสี่ยงที่แท้จริงของคุณนั้นรวมถึงระบบภายนอกทุกระบบที่แอปพลิเคชันของคุณเชื่อถือ ทุกการมอบหมาย DNS, ทุกใบรับรอง TLS อัปสตรีม, API การชำระเงินทุกรายการ, ทุกหน้าสถานะ, ทุกจุดปลายทางบนคลาวด์ที่งาน cron ของคุณขึ้นอยู่กับ สิ่งเหล่านี้คือความสัมพันธ์ที่ไว้วางใจ และความสัมพันธ์��ี่ไว้วางใจลดลงในลักษณะที่ไม่ก่อให้เกิด CVE

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