With the updates to RBACv2 within the Netskope console, it adds Policy Groups. As we investigate this feature and how best to utilize it, we are wondering how other Netskope teams are using them especially when you already have a fully developed policy list.
Howdy @Twoods This is the way I deal with policy groups - header policies are your security/threat/important first pass policies. They always go right on top for threat scans/security category blocks etc. Subsequent policies can be grouped according to your entitlements - My goal is to separate out prod policies from testing policies, lump each in their own policy groups and order them appropriately.
Next, my DLP teams would want access only to the DLP policies, same for SOC/Threat policies, SWG team and SWG policies, NPA etc etc.
@AlfaBane Policy ordering is very important for SWG/CASB inline - hence the recommendation is to position your policies as appropriate. For example - threat blocks/scans ought to be always at the top and then implement other acceptable policy violation related blocks and then do your DLP/CASB/SWG as needed... RBI can also be at the top. below threats ..... DLP is all about scanning things that CANNOT be blocked and needs inspection... (objective is to block as much as possible through your SWG policies and if you can't anymore, ensure that you're scanning content to not allow movement of sensitive data..) Does this help ?
We took the approach of breaking out groups from TEST to PRD. PRD groups are ones that we rely on for actual business and generally are set in stone. These require change tickets for the most part. TEST policies are where we, well, test. They are scoped to a small amount of people (or groups) and can change often while we build them out. Ultimately they would move to PRD. We lump our RBI policies under Web currently.
One thing I dont like is that Header and Footer cannot be renamed. I understand what they are getting at with them but it would be helpful if we could name them something we could internallyt reference that makes more sense.
Valid point - the header footer policies being 'hardcoded' is annoying - Can you DM me the name of your organization and I can open a FR to ask PM to consider providing the ability to edit header footer policy group names