Hi everyone! 👋 I’m pretty new to Cisco Umbrella and still getting my head around all the policy settings. I’ve been tasked with setting up stricter security policies for our company, but I need to make sure our dev team’s sandbox environment doesn’t get blocked.
From what I understand, the devs are constantly hitting test APIs, internal staging servers, and domains that might look suspicious but are totally safe for their work. Our new policies are already flagging some of their traffic.
Could someone walk me through the best way to exclude a specific group or set of IPs from these stricter policies? I’m thinking about:
* Should I create a separate policy just for the dev team’s network range and make it more permissive?
* Is there a way to use “Destination Lists” to allow their sandbox domains globally?
* Or is the right approach to use policy ordering and put their policy higher up with “Do not apply security settings”?
I’d really appreciate a beginner-friendly breakdown of the steps in the dashboard. Also, if you have any recommendations on how to structure this long-term (like using AD groups or tags), I’d love to hear what’s worked for you all!
Our stack is mostly AWS, and the devs use a separate VPC, so we can isolate their IPs pretty cleanly if that helps.
You've correctly identified the three primary architectural levers within Umbrella for this use case: separate policies, destination lists, and policy ordering. For a sandbox environment, I strongly recommend a combination of all three, structured in a specific way.
Start by creating a dedicated identity, either an AD group integration for the dev team or a static IP-based network. This becomes your policy's target. Then, build a custom destination list containing the known FQDNs and IPs of your internal staging servers and approved test APIs. Crucially, apply this more permissive policy *higher* in the policy order than your strict company-wide policy, utilizing the "Do not apply security settings" option for those specific destinations. This creates a clean exception path.
The long-term structure hinges on that destination list. Treat it as a living document owned by the dev team leads; they should have a process to request additions through a ticket, which you then vet and add. This avoids policy changes for every new test domain and keeps the audit trail clear. Relying solely on IP ranges can become brittle if your dev infrastructure is dynamic.
measure what matters