หนี้สิทธิ์การเข้าถึงเครือข่ายที่ AI ทำให้มองข้ามได้ยากขึ้น

ตลอดทศวรรษที่ผ่านมา วงการ cybersecurity ตอบสนองต่อภูมิทัศน์ภัยคุกคามที่เปลี่ยนไปด้วยการเพิ่มชั้นการป้องกันใหม่ ๆ องค์กรลงทุนใน endpoint security, identity, cloud security, vulnerability management, detection and response และล่าสุดคือเครื่องมือด้านความปลอดภัยที่ขับเคลื่อนด้วย AI การลงทุนเหล่านั้นจำเป็นอย่างยิ่ง เพราะพื้นผิวการโจมตีเปลี่ยนไป และทีมความปลอดภัยก็ปรับตัวตาม แต่ภายใต้มาตรการควบคุมเหล่านั้น สิ่งที่เก่าแก่กว่ามากยังคงสะสมต่อเนื่อง นั่นคือสิทธิ์การเข้าถึงเครือข่าย แอปพลิเคชันถูกย้าย เซิร์ฟเวอร์ถูกเปลี่ยน องค์กรย้าย workload ขึ้น cloud การควบรวมกิจการนำโครงสร้างพื้นฐานใหม่เข้ามาในสภาพแวดล้อม การเปลี่ยนแปลง firewall ชั่วคราวกลายเป็นถาวร ข้อยกเว้นยังคงอยู่เพราะการถอดออกมีความเสี่ยงที่จะทำให้ระบบหยุดชะงัก ผลลัพธ์คือความจริงที่ทีมความปลอดภัยจำนวนมากรู้ดีเกินไป นั่นคือ เราไม่ได้ตั้งใจออกแบบโมเดลการเข้าถึงขององค์กรในวันนี้ แต่เราได้รับสืบทอดมันมา เป็นเวลาหลายปีที่ความซับซ้อนซึ่งมาพร้อมมรดกดังกล่าวถูกมองว่าเป็นเพียงเรื่องสุขอนามัยของ firewall หรือหนี้ทางเทคนิค ค่อยจัดการเมื่อมีเวลา ทบทวน rule เก่าในการตรวจสอบรอบหน้า อย่าไปแตะ policy ที่ไม่มีใครเข้าใจ เว้นแต่จำเป็นจริง ๆ แต่การค้นหาช่องโหว่ด้วย AI การวิเคราะห์เส้นทางการโจมตี และการระบุจุดเสี่ยงที่เปิดเผย กำลังเปลี่ยนสมการนี้ ประเด็นไม่ได้อยู่ที่ว่า firewall policy ของคุณสะอาดหรือไม่เท่านั้น แต่อยู่ที่ว่าสิทธิ์การเข้าถึงที่สะสมมาหลายปีกำลังเปิดเส้นทางให้ผู้โจมตีในแบบที่ธุรกิจไม่ต้องการแล้วหรือไม่ และทีมความปลอดภัยของคุณจะกำจัดเส้นทางเหล่านั้นได้อย่างมั่นใจหรือไม่เมื่อถึงเวลาจำเป็น

ตัวเลขบอกเล่าเรื่องราวว่าเรามาถึงจุดนี้ได้อย่างไร

ข้อมูลจาก FireMon Insights เปิดให้เห็นขนาดของปัญหาในสภาพแวดล้อมองค์กรจริง สถิติแต่ละตัวน่าตกใจในตัวเอง และเมื่อนำมารวมกัน ก็สะท้อนภาพใหญ่ว่าสิทธิ์การเข้าถึงเครือข่ายสะสมขึ้นได้อย่างไร และเหตุใดการถอดออกจึงยากเย็นนัก

69% ของ firewall rule ไม่ถูกใช้งาน

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

45% ไม่มีเจ้าของหรือเอกสารกำกับ

ผลการวิเคราะห์อีกข้อหนึ่งจาก FireMon Insights ช่วยอธิบายว่าเหตุใดหนี้ก้อนนี้จึงกำจัดได้ยาก 45% ของ firewall rule ไม่มีเจ้าของหรือเอกสารกำกับ ลองนึกภาพว่าคุณเป็นวิศวกรที่รับผิดชอบการล้าง rule ที่ไม่ถูกใช้งาน คุณเห็นว่ามันไม่ได้ถูกใช้ แต่ไม่รู้ว่าใครเป็นคนร้องขอ ไม่มีเหตุผลทางธุรกิจที่บันทึกไว้ ไม่ชัดเจนว่าใครเป็นเจ้าของแอปพลิเคชัน และคุณไม่สามารถระบุได้ทันทีว่าจะเกิดอะไรขึ้นหากถอดมันออก การตัดสินใจแบบใดปลอดภัยกว่าในเชิงปฏิบัติการ บ่อยครั้งคำตอบคือปล่อย rule นั้นไว้ตามเดิม การตัดสินใจเช่นนี้สมเหตุสมผลเมื่อมองแยกเป็นกรณี ๆ เพราะการทำให้ระบบ production ล่มเพราะถอด firewall rule ที่ไม่มีคำอธิบายออก เป็นปัญหาเฉพาะหน้าที่หนักกว่าการปล่อยสิทธิ์ที่ไม่ได้ใช้ไว้ แต่เมื่อตัดสินใจแบบนี้ซ้ำ ๆ ทั่วทั้งองค์กรเป็นเวลาหลายปี ผลที่ตามมาย่อมมีนัยสำคัญ องค์กรรับสืบทอดสิทธิ์การเข้าถึงที่ไม่มีใครเข้าใจอย่างถ่องแท้ และก็ไม่มีใครมั่นใจพอที่จะถอดออก

ความซับซ้อนลงลึกกว่าระดับ rulebase

รูปแบบเดียวกันนี้ปรากฏในระดับที่ลึกกว่า rule แต่ละรายการ FireMon Insights พบว่า 95% ของ firewall application object ไม่ถูกใช้งาน อีกครั้ง ประเด็นไม่ได้อยู่ที่ว่า object ที่ไม่ถูกใช้งานเป็นอันตรายในตัวเอง แต่ตัวเลขนี้แสดงให้เห็นว่าโครงสร้างพื้นฐานในอดีตสะสมอยู่ภายใน network policy ได้มากเพียงใด rule, object, แอปพลิเคชัน และข้อกำหนดด้านการเข้าถึงยังคงอยู่ แม้สภาพแวดล้อมรอบตัวจะเปลี่ยนไปแล้วก็ตาม เมื่อเวลาผ่านไป ช่องว่างก็ยิ่งกว้างขึ้นระหว่างสิ่งที่เครือข่ายอนุญาตกับสิ่งที่ธุรกิจต้องการจริง ๆ และนั่นคือจุดที่ปัญหาด้านการจัดการ policy กลายเป็นปัญหาด้านความปลอดภัย

สิทธิ์ที่ไม่ถูกใช้งานคือพื้นผิวการโจมตีที่แฝงอยู่

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

การถอด rule ไม่เท่ากับการถอดสิทธิ์การเข้าถึง

สิทธิ์ที่ไม่ถูกใช้งานเป็นเพียงด้านหนึ่งของปัญหา FireMon Insights ยังพบว่า 17% ของ firewall rule ซ้ำซ้อนหรือถูกบดบัง ฟังดูเหมือนเป็นสถิติเรื่องการล้าง rule อีกข้อหนึ่ง แต่ความซ้ำซ้อนและความซับซ้อนของ policy สร้างความเสี่ยงด้านความปลอดภัยที่แยบยลกว่านั้น นั่นคือมันบั่นทอนการทำ remediation เอง ลองนึกภาพว่าทีมความปลอดภัยพบช่องโหว่ร้ายแรงในแอปพลิเคชันหนึ่ง ทีมตรวจสอบและพบว่าแอปพลิเคชันที่มีช่องโหว่นั้นเข้าถึงได้ผ่าน firewall rule หนึ่ง เมื่อสิทธิ์นั้นไม่จำเป็น วิศวกรจึงถอด rule ออก การเปลี่ยนแปลงสำเร็จ rule หายไป ตั๋วงาน remediation ถูกปิด มีเพียงปัญหาเดียวคือ สิทธิ์การเข้าถึงอาจยังคงอยู่ rule ที่กว้างกว่าอาจอนุญาตการสื่อสารเดียวกันโดยอิสระ policy ที่ซ้อนทับกันอาจยอมให้ทราฟฟิกผ่าน firewall อีกตัวอาจเปิดเส้นทางอื่น ในสภาพแวดล้อม cloud จุดบังคับใช้อีกจุดหนึ่งหรือ policy ของ microsegmentation ก็อาจยังอนุญาตการเชื่อมต่อนั้นอยู่ ทีมงานถอดการกำหนดค่าหนึ่งออกได้สำเร็จ แต่นั่นไม่ได้แปลว่าได้ถอดสิทธิ์การเข้าถึงออกไปด้วยเสมอไป ข้อแตกต่างนี้สำคัญอย่างยิ่ง เพราะองค์กรอาจเชื่อว่าได้กำจัดจุดเสี่ยงไปแล้ว ทั้งที่เส้นทางการสื่อสารที่ผู้โจมตีต้องการยังคงเปิดอยู่ คุณภาพ policy ที่ไม่ดีไม่ได้เพิ่มพื้นผิวการโจมตีเท่านั้น แต่ยังบั่นทอนประสิทธิผลของ remediation เองด้วย

Effective access คือผลลัพธ์ที่สำคัญจริง

ด้วยเหตุนี้ ทีมความปลอดภัยจึงต้องคิดให้ไกลกว่าการกำหนดค่า firewall แต่ละจุด และเข้าใจ effective access rule บอกคุณได้ว่าการกำหนดค่านั้น ๆ อนุญาตอะไร แต่ไม่ได้บอกเสมอไปว่าสินทรัพย์สองรายการสื่อสารกันได้จริงหรือไม่ตลอดทั้งสภาพแวดล้อม การเข้าถึงเครือข่ายในปัจจุบันอาจขึ้นอยู่กับปฏิสัมพันธ์ระหว่าง firewall policy, ลำดับของ rule, network object, การกำหนดเส้นทาง, การควบคุมบน cloud, policy ของ microsegmentation และจุดบังคับใช้หลายจุดจากผู้ให้บริการหลายราย ทีมความปลอดภัยจึงต้องตอบคำถามที่มีผลมากกว่า "เราถอด rule ออกแล้วหรือยัง" สิ่งที่ต้องรู้คือ การสื่อสารที่ไม่พึงประสงค์ยังเกิดขึ้นได้อยู่หรือไม่ นั่นคือการเปลี่ยน remediation จากการจัดการการกำหนดค่าไปสู่ผลลัพธ์ด้านความปลอดภัย remediation ไม่ได้สำเร็จเพราะมีการลบ firewall rule ออก แต่สำเร็จเมื่อสิทธิ์การเข้าถึงที่ไม่พึงประสงค์นั้นไม่มีอยู่อีกต่อไป ฟังดูเหมือนเป็นความต่างเล็กน้อย แต่ในเครือข่ายองค์กรที่ซับซ้อน มันไม่เล็กเลย

AI บีบเวลาที่ฝ่ายป้องกันมีเหลือให้ทำเรื่องนี้ให้ถูกต้อง

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

นำหลัก least privilege มาใช้กับเครือข่าย

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

1. สิทธิ์การเข้าถึงใดบ้างที่มีอยู่จริง
2. เหตุใดจึงมีสิทธิ์นั้นอยู่
3. ยังจำเป็นอยู่หรือไม่
4. policy และจุดบังคับใช้ใดบ้างที่เปิดสิทธิ์นั้น
5. จะเกิดอะไรขึ้นหากถอดหรือแก้ไขสิทธิ์นั้น
6. หลังทำ remediation เราตรวจสอบยืนยันได้หรือไม่ว่าสิทธิ์ที่ไม่พึงประสงค์หมดไปจริง

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

เหตุใด NSPM จึงสำคัญยิ่งกว่าที่เคย

ตลอดทศวรรษที่ผ่านมา วงการ cybersecurity ตอบสนองต่อปัญหาใหม่ด้วยหมวดหมู่ความปลอดภัยใหม่ ๆ บางครั้งนั่นก็คือสิ่งที่จำเป็นจริง ๆ แต่โมเดลภัยคุกคามที่เปลี่ยนไปก็ทำให้พื้นฐานด้านความปลอดภัยที่มีอยู่เดิมกลับมามีความสำคัญเชิงกลยุทธ์อีกครั้งได้เช่นกัน Network Security Policy Management ถูกสร้างขึ้นเพื่อช่วยให้องค์กรเข้าใจและควบคุม effective access ทั่วทั้งสภาพแวดล้อมที่ซับซ้อน ซึ่งรวมถึงการระบุสิทธิ์ที่ไม่ถูกใช้งานและสิทธิ์ที่กว้างเกินไป การค้นหา policy ที่ซ้ำซ้อนหรือซ้อนทับกัน การกำหนดเจ้าของและเหตุผลทางธุรกิจ การวิเคราะห์การใช้งาน policy การจำลองการเปลี่ยนแปลง และการถอดสิทธิ์ที่ไม่จำเป็นออกอย่างปลอดภัย ที่สำคัญยิ่งคือการเข้าใจ policy ในฐานะส่วนหนึ่งของโมเดลการเข้าถึงภาพรวม แทนที่จะพิจารณา rule แต่ละรายการแบบแยกส่วน ความสามารถเหล่านี้ไม่ได้เพิ่งกลายเป็นเรื่องใหม่เพราะ AI แต่ความสำคัญของมันเปลี่ยนไปเพราะสภาพแวดล้อมภัยคุกคามเปลี่ยนไป เมื่อผู้โจมตีสามารถระบุและใช้ประโยชน์จากจุดอ่อนได้เร็วขึ้น องค์กรก็มีพื้นที่เหลือน้อยลงสำหรับสิทธิ์การเข้าถึงที่ไม่จำเป็น ไม่เข้าใจ หรือไม่กล้าถอดออกอย่างมั่นใจ

เป้าหมายไม่ใช่นโยบายที่สะอาดขึ้น แต่คือการลดสิทธิ์การเข้าถึงที่ไม่จำเป็น

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

เปลี่ยนความซับซ้อนของนโยบายให้เป็นการควบคุมนโยบาย

FireMon ช่วยให้ทีมความปลอดภัยก้าวข้ามการบริหารจัดการกฎทีละข้อ ไปสู่การทำความเข้าใจและควบคุมสิทธิ์การเข้าถึงที่เกิดขึ้นจริงทั่วทั้งเครือข่าย on-prem สภาพแวดล้อมคลาวด์ และเทคโนโลยี microsegmentation ด้วยการวิเคราะห์นโยบายอย่างต่อเนื่อง การวิเคราะห์เส้นทาง การปรับกฎให้เหมาะสม การจำลองการเปลี่ยนแปลง และการกำกับดูแลนโยบาย ทีมงานสามารถระบุการเชื่อมต่อที่ไม่จำเป็น ลดเส้นทางการเข้าถึงที่ไม่พึงประสงค์ และสร้างความมั่นใจได้มากขึ้นว่านโยบาย firewall ทำงานตามที่ตั้งใจไว้ เพราะเป้าหมายไม่ใช่เพียงชุดกฎที่สะอาดขึ้น แต่คือสิทธิ์การเข้าถึงที่ไม่จำเป็นที่ลดลง Policy is Power.