Domains

What Is Domains?

In FireMon Security Manager, domains are a multi-tenant feature that separates devices, data, and workflows into an Enterprise domain and one or more customer domains. They let administrators segregate customer or business unit environments within a single Security Manager deployment, combining with device groups and role-based access to control what each domain can see and manage.

Key takeaways

• Domains split a Security Manager deployment into an Enterprise domain and one or more customer domains, primarily for multi-tenant, MSSP-style use.
• In an MSSP deployment, a device group can belong to only one domain, and the devices within it can belong to only one domain.
• Settings like central syslog servers can be scoped at the Enterprise domain level, where they're available to every customer domain, or at the customer domain level, where they stay limited to that domain.
• Domains work alongside device groups and role-based access controls to keep customer or business unit data and workflows separate within one platform.

Why Domains Matter

Managed security providers and large enterprises often run one Security Manager deployment but need to keep different customers' or business units' devices, policy data, and workflows from mixing. Without that separation, an analyst working on one customer's firewalls could accidentally see or touch another customer's devices, and reporting would blur together instead of reflecting one engagement at a time. Domains exist to solve that problem directly: they give administrators a way to segment a single FireMon instance into distinct, access-controlled sections, so multiple customer environments can be managed from one platform without their data and workflows bleeding into each other.

This matters operationally as much as it matters for security. Service providers that manage firewall policy for many customers need a repeatable way to onboard a new account without rebuilding their process each time, and domains are part of how that repeatability gets built into the platform.

How Domains Work

A Security Manager deployment used in an MSSP context is organized around an Enterprise domain and one or more customer domains underneath it. The Enterprise domain sits at the top level, while each customer domain holds the devices, device groups, and configuration specific to that customer.

Some settings are explicitly scoped to one level or the other. Central syslog servers, for example, can be created at the Enterprise domain level, where they become available to devices across every customer domain in the deployment, or at the customer domain level, where they're available only within that single customer domain. That distinction lets an administrator decide whether a given piece of configuration should be shared across the whole deployment or kept isolated to one customer.

Device groups follow a similar logic. In an MSSP deployment, a device group can belong to only one domain, and the individual devices within that group can likewise belong to only one domain. That constraint keeps a customer's devices from ending up split across domain boundaries by accident.

Access to domains is also permission-controlled. Managing devices requires specific system permissions, including a dedicated "Domains" permission for MSSP use, which determines whether a given user can see or administer domain-level settings at all. Domain administration itself, including creating and editing domains, is handled through the system administration area of Security Manager.

A Realistic Example

Consider an MSSP bringing on a new customer. The provider creates a customer domain for that account and places the customer's firewalls and device groups inside it, so only analysts assigned to that domain can see or work with those devices. Meanwhile, the MSSP configures a central syslog server once at the Enterprise domain level, making it available automatically to every customer domain in the deployment, rather than reconfiguring syslog settings customer by customer. The result is a new customer onboarded into a segregated workspace without duplicating shared infrastructure settings.

The Operational Consequence

When domains are set up correctly, each customer's or business unit's devices, policy data, and workflows stay contained to their own section of the platform, and the people working in one domain don't see or affect another. That containment supports cleaner audit evidence, since activity and reports tie back to a specific domain rather than a shared, undifferentiated pool of devices. It also supports operational efficiency for MSSPs: rather than running separate tools or separate deployments for every customer, one platform can host many segregated environments, with Enterprise-level settings reused where it makes sense and customer-level settings kept isolated where it doesn't.

Key Components and Best Practices

A few structural pieces define how domains function in practice:

• Enterprise domain: the top-level domain in an MSSP deployment; settings created here, such as central syslog servers, can be made available across all customer domains.
• Customer domains: domain-level segments that hold devices, device groups, and data for a specific customer or business unit, kept separate from other customer domains.
• Device groups scoped to a domain: in an MSSP deployment, device groups and the devices inside them belong to exactly one domain, which prevents a customer's devices from being split across domain boundaries.
• Domain-aware permissions: system-level permissions, including a dedicated permission for domains, control who can view or administer domain settings.

Planning domain structure before onboarding customers, and understanding which settings belong at the Enterprise level versus the customer level, helps avoid rework later.

Common Challenges

Because a device group and its devices can belong to only one domain in an MSSP deployment, getting domain assignment wrong early on, placing devices in the wrong customer domain, for instance, means moving them later rather than simply adding extra scope. Deciding which configuration items should live at the Enterprise domain level versus the customer domain level also takes some planning, since settings like central syslog servers behave differently depending on where they're created.

How This Connects to Network Security Policy Management and FireMon

Domains are one of the mechanisms FireMon, the founder of NSPM, uses to apply network security policy management consistently across multiple customer or business unit environments from a single deployment. Rather than running isolated tools for each customer, domains let Security Manager segregate devices, data, and workflows while still giving administrators one consistent platform for policy visibility, normalization, and governed change across every segregated environment.