I brought this issue to support, and was told to vote up a feature request. Absolutely shocked that was the answer, given how important this is. I'd think a company that markets security would be more proactive, instead of waiting for the community to ask for reasonable security that has been adopted by most companies or waiting until something goes wrong and be embarrassed by it.
We essentially have to allow unsigned MSI files to upgrade stations which means other unsigned MSI files can run. The core issue as far as I can tell is that the MSI file is dynamically generated. From what I understand this is so that things like company, site, and other values can be included in the MSI. What might work better is to simply read and re-use the current values on an upgrade. For a new install you could use switches to provide the values. This would mean you could have a single signed MSI.
I think this whole issue is contradictory to CW's stance on zero trust at https://www.connectwise.com/blog/cybersecurity/how-to-enforce-a-zero-trust-policy. In that article it is written that a best practice is "Limiting access controls to specific applications, resources, data, and assets, rather than the broader network".
It sure is difficult to limit access controls to specific applications when I have to allow unsigned MSI installers with unique hashes to run.
This is so incredibly important. It is even more important because the installer loves to violate up to 8 TTPs.
Most of these are understandable and could be accepted if the installer was signed.
I brought this issue to support, and was told to vote up a feature request. Absolutely shocked that was the answer, given how important this is. I'd think a company that markets security would be more proactive, instead of waiting for the community to ask for reasonable security that has been adopted by most companies or waiting until something goes wrong and be embarrassed by it.
We essentially have to allow unsigned MSI files to upgrade stations which means other unsigned MSI files can run. The core issue as far as I can tell is that the MSI file is dynamically generated. From what I understand this is so that things like company, site, and other values can be included in the MSI. What might work better is to simply read and re-use the current values on an upgrade. For a new install you could use switches to provide the values. This would mean you could have a single signed MSI.
I think this whole issue is contradictory to CW's stance on zero trust at https://www.connectwise.com/blog/cybersecurity/how-to-enforce-a-zero-trust-policy. In that article it is written that a best practice is "Limiting access controls to specific applications, resources, data, and assets, rather than the broader network".
It sure is difficult to limit access controls to specific applications when I have to allow unsigned MSI installers with unique hashes to run.