Skip to main content
All CollectionsPolicy ManagementHow TosAdvanced Policy [Early Access]
A Guide to Policy Management with SuperOps’ Advanced Policy [Early Access]
A Guide to Policy Management with SuperOps’ Advanced Policy [Early Access]
Updated over a month ago

The Advanced Policy Framework in SuperOps introduces a new way of managing policies for your assets, ensuring greater control, flexibility, and efficiency. With the group-based policy framework, there are often conflicts between policies that apply to assets which belong to multiple asset groups. One asset may have more than one policy set assigned to it, which leads to inconsistencies and a constant need for overrides at a client or an asset level, which is a time consuming, manual task.

With advanced policy, these gaps are addressed, making your policy management seamless, efficient, and a lot more organized. When working with advanced policy in SuperOps, a structured approach can make all the difference in managing your policies effectively. Let's first look at the definitions of the new concepts we have introduced, then explore best practices that will help you make the most of this powerful framework.

Nomenclature

Device Category

This refers to a group of assets (similar to asset groups in group-based policy) that can be managed collectively, such as Windows workstations, Windows servers, Mac workstations, etc. Device categories help you organize assets into logical folders, making it easier to apply policies consistently across similar devices. Device categories are split into two sections: Endpoint and Network Device.

For endpoints, you have the following default device categories:

  • Windows Workstation

  • Windows Server

  • Mac Workstation

  • Mac Server

  • Linux Workstation

  • Linux Server

Under Network Device, you have one default device category for each supported network device type.

Note: A device category is essentially an asset’s OS + Platform. Platform is either workstation or server, while OS could be Windows, Mac, or Linux.


Policy Sets

A policy set is a collection of individual policies such as alerts, patches, software, antivirus, remote desktop settings, and more that govern how an asset will be managed by you. In advanced policy, policy sets are organized in the form of a tree with a root policy set at the top, followed by parent policy sets which can have several child policy sets under it. This tree structure gives you flexibility, ensuring your policy setup is efficient and easy to optimize.

Root Policy Set: This is the base policy configuration for a device category. For a default device category, a root policy set is automatically created and associated. A root policy set includes essential policies such as alerts, patches, antivirus, and software that will be inherited by all child policies.

Parent Policy Set: A policy set that inherits the settings from the root policy set but allows for modifications. It acts as an intermediary between the root policy set and more specific child policy sets. Every policy set that precedes a child is the parent of that child.

Child Policy Set: Every policy set that follows a parent is a child policy set. These are specialized policies that inherit settings from a parent policy set but can be customized further. They allow you to fine-tune configurations for specific scenarios without starting from scratch.

Turn On/Off a policy

Every policy configuration now comes with a toggle that you can use to turn it on or off. This gives you a lot of room for flexibility, without having to worry about what a policy set is going to inherit from its parent. No matter what it inherits, you always have granular control to go and turn off a policy at any level in the tree.

Inheritance

In advanced policy, inheritance is bi-directional which means that a policy configuration introduced at any level is available for use everywhere in the tree. Let’s break this down further:

  • Child policy sets automatically inherit settings from their parent policy sets. You can override inherited settings to customize the policies further, ensuring that specific needs are met.

  • If a new policy such as an alert configuration is introduced in a child policy set, it will automatically appear in all its parents, however, it will be turned off by default.

  • Downward inheritance retains the state of the policies, while upward inheritance keeps the policies at a disabled state always.

Policy Association

Policy association refers to the mapping of policy sets to designated device categories. This linkage ensures that the policy configurations and settings defined in a policy set are automatically applied to all devices within the associated category.

For example, if you have a policy that includes settings for security patches, alerts, and software updates, associating this policy with a device category like "Windows Workstations" means that all devices categorized under Windows Workstations will inherit and adhere to these settings.

Policy association allows you to implement consistent configurations across multiple devices or clients efficiently, without having to apply settings individually. It also facilitates easier updates and maintenance by centralizing any policy changes.

Adjustments made to a policy set automatically apply and propagate to all associated devices. This helps you streamline asset management, enforce uniform standards, and ensure compliance with organizational and contractual requirements.

Best Practices

Organize your assets with Device Categories

First, take some time to categorize your devices thoughtfully. You’ll want to start by grouping assets into logical categories, such as VIP workstations, C-suite devices, managed servers etc. This step is crucial because once your assets are properly categorized, you can easily manage policies for similar devices across different clients.

Consider using device categories that apply globally, especially if you have multiple clients with similar asset types. This will allow you to apply policies across all clients without needing to reinvent the wheel each time.

Build Policy Sets with Inheritance in mind

Begin by creating a solid foundation by defining a root policy set for each device category. This root policy should cover all the essential configurations, like alerts, patches, and software installations. Once this is in place, you can build on it with parent and child policy sets with customized policy configurations. The policy structure works like a tree with the root policy set at the top, branching into child policy sets.

For instance, your parent policies can introduce specific variations tailored to certain client needs or device types. Then, child policies can fine-tune these further. The beauty of this setup is that by using inheritance, you avoid having to redo work across multiple policy sets, and you ensure that all critical settings remain consistent throughout.

Alternatively, you could add all your policy configurations into the root policy and keep them turned off by default, so that they automatically trickle down into all further child policy sets that you create, through inheritance. This way, you can quickly turn on and customize the policies that you need at any child level, without having to create anything from scratch.

Map Policy Sets effectively to Device Categories

Mapping your policies to the correct device categories is where all your preparation pays off. You’ll want to ensure that the right policies are associated with the appropriate categories within each client. For example, you might apply a standard workstation policy to all workstations across your clients, while a more customized policy could be reserved for VIP workstations. Similarly, your root policy set for servers can be associated to all Windows Servers, while a more customized policy set can be associated to Critical Servers.

Inheritance plays a big role here, as it helps propagate the essential settings across all child policies. This means you only need to make manual adjustments where necessary, reducing the chance of errors and making your life easier.

Maintain visibility and control

Regularly monitoring your policy mappings is key to ensuring everything is working as expected. We have added a new policy tab to the client page that is designed to help with this. By keeping an eye on which policies are linked to which device categories, you can quickly identify any gaps or inconsistencies and edit as needed then and there.

Manage patches at a policy level

With the patch management enhancement, you can now approve patches at a policy set level. For example, you can select the VIP windows workstation policy set and approve a patch that needs to apply to all the endpoints that fall under the VIP Windows Workstation category. With the Group-based framework, you have to individually go to each asset and apply a script. With advanced policy, you can do this in one click – simply select the policy set and run the script for all assets in one go.

Streamline client onboarding and management

When bringing new clients on board, take advantage of the policies you’ve already created. Instead of starting from scratch, apply your existing policy sets, making only minor tweaks as needed. This approach not only speeds up the onboarding process but also ensures consistency across your client base.

Lastly, it’s important to periodically review and update your policy sets. As your business grows and your client needs evolve, so should your policies. Revisiting them regularly will help you stay ahead of the curve and maintain effective asset management across all your clients.

If you are currently using the group-based policy management framework and want to move to advanced policy, check out this article to see how you can seamlessly migrate to the new framework without losing your existing policy configurations.

Did this answer your question?