From 4ab57db6a9b929d4d6e32a4b2982e1a44ca1c6e1 Mon Sep 17 00:00:00 2001 From: Herve Date: Mon, 24 Nov 2025 11:31:24 +0100 Subject: [PATCH 1/8] Add documentation for SASE OpsLab whitelisting solution Document the problem, motivation, business opportunity, detailed use cases, and product behavior for SASE OpsLab's dynamic whitelisting solution. --- opslab-src/WhiteListing | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 opslab-src/WhiteListing diff --git a/opslab-src/WhiteListing b/opslab-src/WhiteListing new file mode 100644 index 00000000..4cb8d103 --- /dev/null +++ b/opslab-src/WhiteListing @@ -0,0 +1,32 @@ +#Problem Statement + +As enterprises transition to SASE (Secure Access Service Edge), they are required to build secure tunnels from their locations to the SSE (Security Service Edge) PoPs (Points of Presence). However, for these tunnels to function correctly, legacy edge firewalls and CPE (routers) must also be configured to allow traffic to the SSE PoPs. +SSE vendors typically provide large IP subnet ranges for these PoPs—often with far more addresses than are actually in use. Whitelisting such broad IP ranges introduces significant security risks, as it expands the attack surface and violates the principle of least privilege. +To reduce this risk, customers prefer to allow traffic only to the specific IP addresses of the PoPs actually in use. However, identifying and managing these specific IPs across hundreds or even thousands of firewalls is operationally burdensome and error-prone. This complexity creates a major obstacle to SASE adoption, particularly in large, distributed environments. + +#Motivation +Without a precise and scalable method for whitelisting only the necessary IP addresses, organizations are forced to choose between weakening their security posture or facing high operational overhead. +A solution that enables dynamic, fine-grained whitelisting—automated and aligned with actual PoP usage—would drastically reduce risk, simplify operations, and accelerate SASE deployments at scale. It would also help network and security teams maintain consistent policy enforcement across all locations, ensuring that SASE does not become a new point of vulnerability. + +# Business Opportunity +SASE OpsLab addresses this challenge by providing automated, dynamic whitelisting to: +- Reduce operational complexity for network and security teams by centralizing and simplifying firewall rule management across heterogeneous and distributed firewalls at the edge +- Improve the security posture by enforcing least-privilege access—ensuring that only the exact, actively-used PoP IPs are permitted, not entire vendor subnets +- Allow for policy consistency and auditability across legacy and virtualized firewalls from different vendors. +By integrating SASE OpsLab into the deployment process, enterprises can accelerate SASE rollouts, reduce misconfiguration risk, and maintain strict security standards without overwhelming their operational teams. + +#Detailed Use Cases (per personas) + +##Mary & Angela - Security Manager & Security Architect +As members of the security leadership team we want to be sure that our firewall policy posture complies with the principle of least privilege. +Therefore we want to open only the traffic to the POPs of our SASE provider. For that we want a solution that automatically collects and maintains the list of POP IP addresses associated with our SASE tenant (organization), and dynamically update firewall whitelisting rules on all edge devices accordingly. +So that the redirection of all outgoing traffic from the edge/branch to the internet and DCs are all allowed to be sent to the right SASE POPs +##Sebastian Managed SASE provider operator +Sebastian receives repeated requests to configure access only to the specific IPs of the PoPs actually used by its customer’s users. He must manually configure numerous NGFW which is cumbersome and time consuming. He may have created scripts but those are not productized nor dynamic. +Sebastian uses SASE OpsLab as an automation and orchestration layer to simplify and secure this process. The SASE OpsLab queries the SSE vendor APIs to determine which PoPs are actively used by each customer/site. It then pushes the necessary firewall rules to the appropriate customer edge devices. + +#Product Behavior +The OpsLab stores the complete list of IP addresses (IPv4 and/or IPv6) associated with the customer’s assigned POPs. +##Rule Generation and Deployment: + Based on the maintained list, the OpsKit generates or updates firewall rules to whitelist only these IPs. These rules are pushed and enforced across all customer-associated edge devices (e.g., CPE, uCPE, vCPE). + From caf5ad042a9a0fe66dd2a06e51b1b8f47f7371dd Mon Sep 17 00:00:00 2001 From: Antoine Brun Date: Mon, 24 Nov 2025 12:11:09 +0100 Subject: [PATCH 2/8] Update opslab-src/WhiteListing Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- opslab-src/WhiteListing | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/opslab-src/WhiteListing b/opslab-src/WhiteListing index 4cb8d103..a9be20b5 100644 --- a/opslab-src/WhiteListing +++ b/opslab-src/WhiteListing @@ -1,4 +1,4 @@ -#Problem Statement +# Problem Statement As enterprises transition to SASE (Secure Access Service Edge), they are required to build secure tunnels from their locations to the SSE (Security Service Edge) PoPs (Points of Presence). However, for these tunnels to function correctly, legacy edge firewalls and CPE (routers) must also be configured to allow traffic to the SSE PoPs. SSE vendors typically provide large IP subnet ranges for these PoPs—often with far more addresses than are actually in use. Whitelisting such broad IP ranges introduces significant security risks, as it expands the attack surface and violates the principle of least privilege. From 5d387880c69885154beef130b3d58ec151a8d10f Mon Sep 17 00:00:00 2001 From: Antoine Brun Date: Mon, 24 Nov 2025 12:11:18 +0100 Subject: [PATCH 3/8] Update opslab-src/WhiteListing Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- opslab-src/WhiteListing | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/opslab-src/WhiteListing b/opslab-src/WhiteListing index a9be20b5..03a38753 100644 --- a/opslab-src/WhiteListing +++ b/opslab-src/WhiteListing @@ -4,7 +4,7 @@ As enterprises transition to SASE (Secure Access Service Edge), they are require SSE vendors typically provide large IP subnet ranges for these PoPs—often with far more addresses than are actually in use. Whitelisting such broad IP ranges introduces significant security risks, as it expands the attack surface and violates the principle of least privilege. To reduce this risk, customers prefer to allow traffic only to the specific IP addresses of the PoPs actually in use. However, identifying and managing these specific IPs across hundreds or even thousands of firewalls is operationally burdensome and error-prone. This complexity creates a major obstacle to SASE adoption, particularly in large, distributed environments. -#Motivation +# Motivation Without a precise and scalable method for whitelisting only the necessary IP addresses, organizations are forced to choose between weakening their security posture or facing high operational overhead. A solution that enables dynamic, fine-grained whitelisting—automated and aligned with actual PoP usage—would drastically reduce risk, simplify operations, and accelerate SASE deployments at scale. It would also help network and security teams maintain consistent policy enforcement across all locations, ensuring that SASE does not become a new point of vulnerability. From 55ebd96f91f8de45135aca26b3c0ed4434af9f41 Mon Sep 17 00:00:00 2001 From: Antoine Brun Date: Mon, 24 Nov 2025 12:11:27 +0100 Subject: [PATCH 4/8] Update opslab-src/WhiteListing Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- opslab-src/WhiteListing | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/opslab-src/WhiteListing b/opslab-src/WhiteListing index 03a38753..cc45c93f 100644 --- a/opslab-src/WhiteListing +++ b/opslab-src/WhiteListing @@ -17,7 +17,7 @@ By integrating SASE OpsLab into the deployment process, enterprises can accelera #Detailed Use Cases (per personas) -##Mary & Angela - Security Manager & Security Architect +## Mary & Angela - Security Manager & Security Architect As members of the security leadership team we want to be sure that our firewall policy posture complies with the principle of least privilege. Therefore we want to open only the traffic to the POPs of our SASE provider. For that we want a solution that automatically collects and maintains the list of POP IP addresses associated with our SASE tenant (organization), and dynamically update firewall whitelisting rules on all edge devices accordingly. So that the redirection of all outgoing traffic from the edge/branch to the internet and DCs are all allowed to be sent to the right SASE POPs From 5a230e5498f4c46c1715a3aaf2c21e5df0db0b25 Mon Sep 17 00:00:00 2001 From: Antoine Brun Date: Mon, 24 Nov 2025 12:11:44 +0100 Subject: [PATCH 5/8] Update opslab-src/WhiteListing Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- opslab-src/WhiteListing | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/opslab-src/WhiteListing b/opslab-src/WhiteListing index cc45c93f..400ceddc 100644 --- a/opslab-src/WhiteListing +++ b/opslab-src/WhiteListing @@ -20,7 +20,7 @@ By integrating SASE OpsLab into the deployment process, enterprises can accelera ## Mary & Angela - Security Manager & Security Architect As members of the security leadership team we want to be sure that our firewall policy posture complies with the principle of least privilege. Therefore we want to open only the traffic to the POPs of our SASE provider. For that we want a solution that automatically collects and maintains the list of POP IP addresses associated with our SASE tenant (organization), and dynamically update firewall whitelisting rules on all edge devices accordingly. -So that the redirection of all outgoing traffic from the edge/branch to the internet and DCs are all allowed to be sent to the right SASE POPs +So that the redirection of all outgoing traffic from the edge/branch to the internet and DCs are allowed to be sent to the right SASE POPs ##Sebastian Managed SASE provider operator Sebastian receives repeated requests to configure access only to the specific IPs of the PoPs actually used by its customer’s users. He must manually configure numerous NGFW which is cumbersome and time consuming. He may have created scripts but those are not productized nor dynamic. Sebastian uses SASE OpsLab as an automation and orchestration layer to simplify and secure this process. The SASE OpsLab queries the SSE vendor APIs to determine which PoPs are actively used by each customer/site. It then pushes the necessary firewall rules to the appropriate customer edge devices. From cfbcb823c61139bf4dfb6f217ce27654ce227a63 Mon Sep 17 00:00:00 2001 From: Antoine Brun Date: Mon, 24 Nov 2025 12:12:05 +0100 Subject: [PATCH 6/8] Update opslab-src/WhiteListing Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- opslab-src/WhiteListing | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/opslab-src/WhiteListing b/opslab-src/WhiteListing index 400ceddc..3755777f 100644 --- a/opslab-src/WhiteListing +++ b/opslab-src/WhiteListing @@ -21,7 +21,7 @@ By integrating SASE OpsLab into the deployment process, enterprises can accelera As members of the security leadership team we want to be sure that our firewall policy posture complies with the principle of least privilege. Therefore we want to open only the traffic to the POPs of our SASE provider. For that we want a solution that automatically collects and maintains the list of POP IP addresses associated with our SASE tenant (organization), and dynamically update firewall whitelisting rules on all edge devices accordingly. So that the redirection of all outgoing traffic from the edge/branch to the internet and DCs are allowed to be sent to the right SASE POPs -##Sebastian Managed SASE provider operator +## Sebastian - Managed SASE Provider Operator Sebastian receives repeated requests to configure access only to the specific IPs of the PoPs actually used by its customer’s users. He must manually configure numerous NGFW which is cumbersome and time consuming. He may have created scripts but those are not productized nor dynamic. Sebastian uses SASE OpsLab as an automation and orchestration layer to simplify and secure this process. The SASE OpsLab queries the SSE vendor APIs to determine which PoPs are actively used by each customer/site. It then pushes the necessary firewall rules to the appropriate customer edge devices. From 8d521c0994e85fd8e8661215fc8b9a1a090a97f7 Mon Sep 17 00:00:00 2001 From: Antoine Brun Date: Mon, 24 Nov 2025 12:14:07 +0100 Subject: [PATCH 7/8] =?UTF-8?q?=F0=9F=8E=AA=20add=20.md=20extension?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- opslab-src/{WhiteListing => WhiteListing.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename opslab-src/{WhiteListing => WhiteListing.md} (100%) diff --git a/opslab-src/WhiteListing b/opslab-src/WhiteListing.md similarity index 100% rename from opslab-src/WhiteListing rename to opslab-src/WhiteListing.md From b9dc927212afa88ffe9bf6664ce1975cc51ccc32 Mon Sep 17 00:00:00 2001 From: Antoine Brun Date: Mon, 24 Nov 2025 12:16:42 +0100 Subject: [PATCH 8/8] =?UTF-8?q?=F0=9F=8E=AA=20review?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- opslab-src/WhiteListing.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/opslab-src/WhiteListing.md b/opslab-src/WhiteListing.md index 3755777f..3298b33f 100644 --- a/opslab-src/WhiteListing.md +++ b/opslab-src/WhiteListing.md @@ -12,17 +12,17 @@ A solution that enables dynamic, fine-grained whitelisting—automated and align SASE OpsLab addresses this challenge by providing automated, dynamic whitelisting to: - Reduce operational complexity for network and security teams by centralizing and simplifying firewall rule management across heterogeneous and distributed firewalls at the edge - Improve the security posture by enforcing least-privilege access—ensuring that only the exact, actively-used PoP IPs are permitted, not entire vendor subnets -- Allow for policy consistency and auditability across legacy and virtualized firewalls from different vendors. +- Allow for policy consistency and the ability to audit across legacy and virtualized firewalls from different vendors. By integrating SASE OpsLab into the deployment process, enterprises can accelerate SASE rollouts, reduce misconfiguration risk, and maintain strict security standards without overwhelming their operational teams. #Detailed Use Cases (per personas) -## Mary & Angela - Security Manager & Security Architect -As members of the security leadership team we want to be sure that our firewall policy posture complies with the principle of least privilege. -Therefore we want to open only the traffic to the POPs of our SASE provider. For that we want a solution that automatically collects and maintains the list of POP IP addresses associated with our SASE tenant (organization), and dynamically update firewall whitelisting rules on all edge devices accordingly. -So that the redirection of all outgoing traffic from the edge/branch to the internet and DCs are allowed to be sent to the right SASE POPs -## Sebastian - Managed SASE Provider Operator -Sebastian receives repeated requests to configure access only to the specific IPs of the PoPs actually used by its customer’s users. He must manually configure numerous NGFW which is cumbersome and time consuming. He may have created scripts but those are not productized nor dynamic. +## Mary & Angela: Security Manager & Security Architect +As members of the security leadership team we want to be sure that our firewall policy posture complies with the principle of the least privilege. +Therefore, we want to open only the traffic to the POPs of our SASE provider. For that we want a solution that automatically collects and maintains the list of POP IP addresses associated with our SASE tenant (organization), and dynamically update firewall whitelisting rules on all edge devices accordingly. +So that the redirection of all outgoing traffic from the edge/branch to the internet and DCs are allowed to be sent to the right SASE POPs +## Sebastian: Managed SASE Provider Operator +Sebastian receives repeated requests to configure access only to the specific IPs of the PoPs actually used by its customer’s users. He must manually configure numerous NGFW which is cumbersome and time-consuming. He may have created scripts but those are not productized nor dynamic. Sebastian uses SASE OpsLab as an automation and orchestration layer to simplify and secure this process. The SASE OpsLab queries the SSE vendor APIs to determine which PoPs are actively used by each customer/site. It then pushes the necessary firewall rules to the appropriate customer edge devices. #Product Behavior