เศรษฐศาสตร์เท็จของการรักษาความปลอดภัยแบบไม่ใช้เอเจนต์สำหรับมือถือ

หมายเหตุบรรณาธิการ: โพสต์นี้เผยแพร่ครั้งแรกในเดือนกันยายน 2022 ในภาษา Iดีจีเทค(คุย).

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

วิธีการรักษาความปลอดภัยแบบ ‘Agentless’ และ ‘no code’ มักได้รับการขนานนามว่าเหมาะสมสำหรับการปกป้องธุรกิจที่เน้นอุปกรณ์พกพา และง่ายต่อการเข้าใจว่าทำไมสิ่งนี้จึงสอดคล้องกับทีมพัฒนาและ DevOps อย่างเท่าเทียมกัน เราทุกคนต่างคุ้นเคยกับเวลาที่ใช้ในการเผยแพร่แอปมือถือเวอร์ชันใหม่และที่สำคัญกว่านั้นคือระยะเวลาที่ผู้ใช้อัปเดตแอปของตนในภาคสนาม ทำให้บริษัทต่างๆ สามารถเลิกใช้แอปบนอุปกรณ์เคลื่อนที่เวอร์ชันเก่าได้ ด้วยเหตุนี้ เมื่อพิจารณาว่าจะเพิ่ม SDK ใหม่ลงในแอปบนอุปกรณ์เคลื่อนที่ของคุณหรือไม่ คำถามคือ “เราจำเป็นต้องทำเช่นนี้จริงหรือ” แน่ใจว่ามีคนถาม!

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

ข้อควรพิจารณา 1: ปริมาณการใช้ API ทั้งหมดเท่าเทียมกันจริงหรือ

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

• มนุษย์ที่มีเจตนาดี
• มนุษย์ที่มีเจตนาไม่ดี
• บอท/สคริปต์ที่มีเจตนาดี
• บอท/สคริปต์ที่มีเจตนาไม่ดี

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

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

• เซิร์ฟเวอร์อื่น
• เว็บเบราว์เซอร์
• เว็บแอปพลิเคชัน
• แอปพลิเคชั่นมือถือ
• บอทหรือสคริปต์

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

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

ข้อควรพิจารณา 2: การเพิ่มตัวแทนยากจริงหรือ

สิ่งต่างๆ ในชีวิตส่วนใหญ่ต้องการการประนีประนอมและการรักษาความปลอดภัยก็ไม่ต่างกัน หากเป็นไปได้ที่จะระบุแหล่งที่มาและสื่อที่แน่นอนด้วยความมั่นใจ 100% โดยเพียงแค่ตรวจสอบทุกคำขอ API ในสภาพแวดล้อมที่ได้รับการสนับสนุนของคุณ คุณก็จะทำอย่างนั้น

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

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

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

ข้อพิจารณาที่ 3: คุณสามารถรักษาความปลอดภัยให้กับธุรกิจมือถือโดยไม่มีบริบทได้หรือไม่

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

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

ไม่น่าเชื่อว่าคุณสามารถแยกความแตกต่างระหว่าง 4 กรณีข้างต้นด้วยสิ่งที่คุณเห็นในคำขอ API ได้ด้วยตัวเอง มักกล่าวกันว่าในด้านความปลอดภัย บริบทคือทุกสิ่ง และสถานการณ์นี้เป็นตัวอย่างที่สำคัญของสิ่งนั้น

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

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

ข้อควรพิจารณาที่ 4: คุณต้องอัปเดตแอปบนอุปกรณ์เคลื่อนที่เมื่อใดเพื่อความปลอดภัย

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

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

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

มาดูต้นทุนที่แท้จริงของคุณกัน

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

ต้นทุนที่แท้จริงของความพยายามที่จะจัดการกับความปลอดภัยของทราฟฟิกมือถือที่แบ็กเอนด์ล้วนๆ คือต้นทุนในการจัดการกับ:

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

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

สรุป

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

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

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

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

*** นี่คือบล็อกที่รวบรวมโดย Security Bloggers Network จาก Approov Blog ที่เขียนโดย David Stewart อ่านโพสต์ต้นฉบับได้ที่: https://blog.approov.io/the-false-economics-of-agentless-security-for-mobile