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 exists. 

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.