Security Assessments and Hardening of XCP-ng
-
This topic wasn't meant to focus on XCP-ng or XOA, but an entire ecosystem that is your network. While I routinely check my network for vulnerabilities and often am squashing said vulnerability XCP-ng is a different system entirely since it shouldn't be hardened by hand but by the developers through routine patching.
The question that I'm asking here is how does the Vates Team evaluate these vulnerabilities, Qualys, Greenbone, something else?
Is the Vates team open to the community reporting these vulnerabilities openly or would a ticket be best?
-
The question that I'm asking here is how does the Vates Team evaluate these vulnerabilities, Qualys, Greenbone, something else?
I'm not sure what you mean by evaluate vulnerability, especially the list about Qualys, Greenbone…
If you mean how do we track and process them, I cannot talk about XO side, but I can shed some light on XCP-ng side:
- we have an internal dependency-track (DT) with various projects (8.2 default install, 8.2 available packages, same split for 8.3), with a custom SBOM generation, to feed DT
- this is based on CVEs and their Common Platform Enumeration (CPE)
- the main issue here is that not all CVEs fill the CPEs the same way, so there may be some misses
- we're trying to improve the SBOM generation to minimize this
- we also monitor the oss-security mailing list, and some other sources
- DT reports the CVEs that matched, and we can keep them in or mark them internally as not impacted, fixed, etc
- we evaluate the priority for us based on their general criticality, but modulate this depending on if it is in base install or not, if it is a part of the software that is meant to be used as a server, if it related to remote acces, and more
- the one we're impacted by and feel are important, we either update to the latest package version, but now that CentOS 7 is end of life, that's less likely to happen, or try to backport the fix ourselves when possible.
That's for the dom0 side, on the hypervisor side, we're part of the security list of the Xen Project, so we receive the XSAs and integrate them as fast as we can in following our release process, sometime integrating the patches ourselves, sometime going with the XenServer fixes. If we integrate them ourselves we most of the time remove our own integration and move to the one from XenServer as the people working on these fixes are mostly the ones working on the XSAs in the first place so they have a better knowledge and insigts than us.
I hope this answers this question.
Is the Vates team open to the community reporting these vulnerabilities openly or would a ticket be best?
On XCP-ng side, everything that are packages from open source would be reports of publicly disclosed CVEs, so you can openly report them. If people were to find new vulnerabilities it would depend, but should follow a classic private disclosure in the first place:
- if it's in an open source package, the upstream would be the best place to do so
- On the same idea if it's regarding Xen, XAPI, or other Xen Project software, reporting them upstream through the security process is the best way, and it could be nice to drop us a ticket for a heads up too, but that's not mandatory
- if it is for some of the packages directly coming from us, creating a ticket for us to be able to work on it before a public disclosure would be best.
Sorry, you asked about the whole ecosystem, but I'm only able to answer from the XCP-ng side of things.
- we have an internal dependency-track (DT) with various projects (8.2 default install, 8.2 available packages, same split for 8.3), with a custom SBOM generation, to feed DT
-
-
@bleader If we don't have support, what's the best place to report security issues? I submitted one in GitHub about 8 months ago, but I'm guessing it got lost
-
It's all written in the link I just posted
-
@nick.lloyd As mentionned by Olivier the documentation has a mail to contact us, which will create a ticket internally, unrelated to support, that will reach the security team directly.
-
@bleader Thank you for the thorough explanation it greatly helps to understand how the team works to keep these systems secure and functional.
From a generalist standpoint, I'll use publicly availability tools to check for and report on any known vulnerabilities within my network (public and private) to me, and then I'll either address those vulnerabilities by either a patch or more commonly a configuration change within a given system.
These could include my UPSs or switches, Hypervisors, client devices (laptops etc). Addressing these is a huge portion of the work that I have to address in a day to day, and knowing what would be normal convention to saying "hey I found this issue with a commodity vulnerability scanner, is it going to be addressed" is useful.
