WPE policy signing (CERT_MODE=2)

Hi @RJ. 

I can’t speak for the product management team regarding WPE and support for policy signing, however I am interested in understanding your use-case a little further. 

The role of policy signing has its origins in our support for Group Policy, where often the teams crafting EPM policy were separate from those charged with distributing it out to the endpoint estate. As such policy signing provided a way for the integrity of the policy to be maintained where that disconnect existed between author and endpoint. 

In the context of BI (and PM Cloud) the policy configuration is performing within an audited management interface by the EPM administrator, and then delivered directly to the endpoint via the secure authenticated channel created by the client-side adapter to the management platform. 

The policy is then stored in a tamper-protected container on the endpoint, which stops the EPM-enabled user from accessing it, and we have the Agent Protection feature which extends that protection to include true administrators, which mitigates the risk of malicious replacement or alteration of the policy at the endpoint. 

I was curious, are you using Agent Protection today and if not would these controls provide mitigations to the risks you have historically used the policy signing feature to achieve? 

Hi @Paul, I am aware of both the tamper-protected container and the Agent Protection feature, these are great deterrents but they aren’t the same as code-signing policies.

For my organization the purpose of requiring code-signing was a technical control to ensure that only policies created by EPM administrators via enforced trusted code-signing would be functional. Even in a post-mortem review code-signed XMLs could be confirmed.

The threat vectors that I am referring to are largely individuals that are willing to socially engineer Service Desk staff, have unexpected privileged access to a device, processes are running as System, or conceptually a nation-state level actor that has zero-day knowledge to inject unwanted content into policies.

With the above, the tamper-protected container could be temporarily defeated and policies manipulated. Where as CERT_MODE=2, to the best of my knowledge, requires the client to be uninstalled/reinstalled to defeat. As the Service Desk does not have access to the installer files only the code-signing required installation is performed by software automation.

Again with the above threat vectors, defeating Agent Protection while running as system or with some zero day is expected. As the normal controls are based on text strings these are more prone to leak/misuse than a code-signing control. Conceptually a much wider group of individuals (100s of IT support roles) would need access to Agent Protection information, whereas the policy signing private key and certificate would only accessible to a much smaller group of EPM Admins. Allowing for policy code-signing at least delineates these two groups. 

Code signing is a best-practice in general.

I want to thank you for your response as I believe you are effectively providing the insight I was looking for, which is that seemingly CERT_MODE=2’s replacement is Agent Protection. 

Hi @RJ. 

Apologies for the tardy reply.

I just wanted to say, I really appreciate you providing that extra level of detail regarding the underlying challenges you are trying to solve for; in my experience, it’s hugely helpful for the engineering teams as it will allow the us to explore whether other approaches could be used to achieve the same outcome (or whether certificate signing may actually be the best solution). 

I’m going to signpost some of the product team to your post for visibility, because it is certainly an interesting problem, although I lack any influence beyond that, so it may be worthwhile you raising it in the Ideas portal (if you haven’t already)! 

From my experience in tech support I can say that the signed policy feature isn't a widely used one but where it is used customers really come up with some valid use cases for its use and I can see why they want to use it. 

IMO it should have a place in the product going forward because whilst we do have lots of layers of protection to stop people getting hold of it, having a plain text policy file is definitely something that I have personally heard other customers mention as a big risk for them. 

Thank you @Paul and @LukeV for your responses. I have created T2EPM-I-1866 to increase visibility and allow for others to potentially upvote.