Add Assigned Policy filter to Saved Asset Search

Policy inheritance opened a lot of new doors, but sadly a few things were lost in the transition, I think that one of these features could be gained back utilized existing code already present in the Syncro system.

If an ‘Assigned Policy’ filter could be added to Saved Asset Search it would narrow the gap of feature parity before policy inheritance was introduced. Especially if an ‘include all assets within nested folders’ option could be added.

I know that the system has this capability already based on the fact that the fantastic billing system picks up assets based on these criteria. If we were able to utilize the same logic within Asset Searches I would gain back a lot of the use-cases that were depreciated with the gain of policy inheritance.

This proposition would allow searching across all 500+ customers of mine that have any assets listed in a folder with X policy applied, including all nested folders. (hopefully a future “and/or query” option will be available for saved asset searches and then we will be at full feature parity)

4 Likes

I think your heart’s in the right place, but we need to start looking at things through the lens of Policy Inheritance…

Syncro removed the Assigned Policy filter, because implementing Policy Inheritance effectively breaks the backend database logic that the filter relies on. Policy Inheritance (PI) is a paradigm shift from the simple 1-to-1 policy to asset assignments. PI has a lot of benefits, but also breaks a lot of the existing codebase. With this new paradigm, we need to change how we think about policies. We’re not assigning a single policy to an asset anymore, so we should stop worrying about trying to figure out which policy is assigned to which asset. That no longer matters.

In the new PI model, policies are assigned to Policy Folders. Therefore, all we should care about is which policy is assigned to which Policy Folder. Because that assignment is what controls which assets get which policies.

Maybe you can help me out, but I don’t see how my philosophy is not using the lens of policy inheritance any different than yours. Since assets or policy folders can be assigned policies isn’t the end goal of either or our desires to know which asset, or groups of assets, ‘said policy’ is touching? It has nothing to do with 1-to-1 assignment. I can see that the report that you are asking for is granting a great overview for auditing, but I wanted to mention a way using existing code that will solve problems for people.
For our team, 1 policy that we have and use across a subset of many policy folders is Bitdefender, and without a way to know which assets have a particular policy touching them I can’t know which assets are positioned to have Bitdefender, compared to which assets actually do.

Maybe an analogy will help. Imagine your office goes from sending out legal documents via fax, to sending out legal documents via email. Now your staff is complaining, I can’t send documents to a phone number anymore. Please make it so I can send emails to phone numbers. First off, people shouldn’t be using phone numbers anymore, because using emails is so much better. Second, you can’t just rip the guts out of your old fax machine, and put them into a computer. It would require a significant redesign. Plus how would you handle a Reply All? Fax machines (phone lines) aren’t capable of that.

In much the same way, Syncro can’t just re-enable the old Policy Assigned filter logic. That too would require a significant redesign. Take if from someone who’s worked with databases for 13+ years, the backend on Policy Inheritance (PI) is going to look completely different than the old “Flat” Policy Assignments.

IMO, this would be a nice to have (not required) feature. My primary goal was to do Policy Management and Cleanup, which requires knowing where policies are assigned, not specifically where they’re applied. In the old Flat Policy Assignment methodology, “assigned” and “applied” were effectively the same thing. But this is no longer the case with Policy Inheritance (PI).

  • Assigned - The linking of a policy to a single Policy Folder or Asset (even in PI, you can still link a policy at the asset level).
  • Applied - When the settings within a policy modify the asset’s Effective Policy in some way.

From an engineering perspective, calculating where a policy is assigned is much easier than calculating where it’s applied. Syncro has limited resources and a budget, so they’d be wise to focus on the features that provide the most benefit for the least investment. Also, if you structure your policies to overlap nicely, then knowing where they’re assigned is more useful than knowing where they’re specifically applied (more on that later).

Active Directory GPOs
Let’s take a brief look at Active Directory GPOs. That’s another type of Policy Inheritance model. You can view what OU(s) a GPO is linked to, but you can’t see the specific workstations and users that the GPO is applied to. This is not be accident. Yes, you can run the Group Policy Results wizard to see how GPOs are applied to a specific user and computer, but Syncro has an equivalent feature too. It’s called View Effective Policy. Syncro also gives us View in Policy Folder to help us quickly see where the asset resides in the PI hierarchy. These two features allow us to successfully manage policies on a single asset. But what about multi-asset policy management?

Policy Inheritance: Multi-Asset Policy Management
This is where we need to start having a PI mindset, and stop trying to keep track of where every single policy is being applied. Instead we should focus on understanding where our policies are assigned. When policies are structured to overlap with one another (an key tenant of good Policy Management) it’s easier to conceptualize how they apply to groups of assets. Organize similar assets into groups (Policy Folders) and ensure the policies applied to the groups make sense. Don’t worry about the individual assets.

Why not try to calculate all the assets that a given policy touches?
When using PI, this is not a great strategy for multiple reasons:

  1. Enterprise networks are big. Trying to track 10s of policies across 10s of thousands of endpoints is a losing battle.
  2. It’s very complex and costly (from a database resource perspective) to calculate which policies effect change across multiple assets. First, you have to determine where the policy is assigned (the goal of my Feature Request). Next, you have to JOIN all the assets that are located in each of the policy folders (or the asset itself). Then look at each asset and determine if it has any policies assigned below the level at which the target policy is assigned. Then compare each lower level policy to the target policy, and determine if the target policy is being superseded. This can be tricky, because some policy sections “stack” together, while other sections overwrite. Now imagine doing that for thousands of assets. To do this effectively, Syncro would need to employ a pre-calculate applied policy table, which would add even more complexity.
  3. It’s not all that useful. Depending on where an asset lives in the Policy Folder structure, and what parts of the policy are defined, and what other policies are defined before or after it, the effects of the policy may be different. As assets move around, and other policies are modified, you can’t rely on a single policy having the same effect across multiple assets.

Conclusion
Instead of asking “What assets does this one policy affect?” you should be asking “How does this one policy affect the whole hierarchy of policies?”. Another good question to ask is “Does this policy fit into my policy layering strategy?”

Thanks for your time. I believe that we both understand the benefit of PI, but applying policies for maintaining a standard vs one-time scripting and reporting needs for the same set of policies are completely different things, and a major discrepancy currently exists that I dear miss being able to offer to my clients. I care about the one-time look in a different nuance than you do, both are necessary, and neither one counters the philosophy of PI. Since the folder based searching does work I can adopt a naming convention to achieve my goal, but one character typo and my data is incorrect, which gets way too easy with 570 customers and 9 policies with differing layering across them all. I hate knowing that I can no longer audit my systems to know when policies are assigned, compared to if the assignment actually deployed correctly. Again, thank you for your time and passion, the world is better off for it.

I also like the ability to search for assets that reside in a Policy Folder by the folder’s name. But be aware that it has a severe limitation. The search results do NOT include assets in subfolders. And Policy Folder names have a 39 character limit, which makes it difficult to include top level folder names within subfolders. You might be able to develop some short-code naming convention to work around this, but it’s not going to be very pretty.