The certificates are used for many things. So as we threat modeled the type of sensitive information that is now flowing through the endpoint fabric meshed network we decided to defend the data using industry standard crypto with certificates. Even though it is our best practices we can't demand our customers to lock down their VSA.
Why so much extra security? We have seen in the field deployments where VSA administrators are NOT using a transport security layer like SSL. It also allows us to encrypt and digitally sign the payload of information so that only the intended recipient can access the data. It allows us to offer mutual authentication so both the VSA and the endpoint fabric can trust each other. When the endpoint first registers itself, the VSA will issue a device certificate to that machine so that only that agent can communicate with the VSA as that device's identity. With the introduction of the new endpoint fabric in v9.3 we also introduced a new public key infrastructure (PKI) that offers both encryption and digital signatures of the payload between the VSA and the endpoint fabric. This agent certificate is present on all managed agents (but each with its own GUID as the Subject). The second certificate is for the locally installed agent and has the VSA GUID as the Issuer, but the subject is another GUID which is unique to each agent. The parent VSA root certificate has the same globally unique identifier (GUID) as the Subject and Issuer, which is the internal system VSA GUID. On the VSA server, there will be two certificates. Starting in R9.3, a digital certificate is installed to the personal store of the VSA server and each managed agent. Why are we now using digital certificates?
0 kommentar(er)
