This may be covered elsewhere, but I'll add just in case.
The packages contains instructions that could significantly modify the structure of a customer's indices; ILM policy, transforms, mappings etc. We should not be reliant solely on HTTPS DNS name validation to prove provenance of the package. A determined state level attacker could forge a certificate and play man in the middle on any of the requests, serving up packages intended to disrupt the target.
This will become a larger issue as we add more content to the packages. I am thinking, for example, of SIEM ruleset for Elastic Security. In that case, an attacker could undermined a target's security posture by replacing or modifying effective detection rules.
The packages should be signed much like the code we deliver to customers. The recipient, in this case Kibana, should validate the signature before installation. To support non-elastic or dev packages, the UI should warn if a package is not signed, but allow the customer to override.
This may be covered elsewhere, but I'll add just in case.
The packages contains instructions that could significantly modify the structure of a customer's indices; ILM policy, transforms, mappings etc. We should not be reliant solely on HTTPS DNS name validation to prove provenance of the package. A determined state level attacker could forge a certificate and play man in the middle on any of the requests, serving up packages intended to disrupt the target.
This will become a larger issue as we add more content to the packages. I am thinking, for example, of SIEM ruleset for Elastic Security. In that case, an attacker could undermined a target's security posture by replacing or modifying effective detection rules.
The packages should be signed much like the code we deliver to customers. The recipient, in this case Kibana, should validate the signature before installation. To support non-elastic or dev packages, the UI should warn if a package is not signed, but allow the customer to override.