search

CESNET / pakiti-server

Pakiti provides a monitoring mechanism to check the patching status of Linux systems.
BSD 2-Clause "Simplified" License
49 stars 35 forks source link

Enhancement - CVSS scores #152

Open lucasnetau opened 6 years ago

lucasnetau commented 6 years ago

Hi, I've been making some enhancements to pull in CVSS scores into the Pakiti database. Along with the ability to identify the highest risk systems.

Is this something you would be willing to include?

kouril commented 6 years ago

In principle yes, the final answer will depend on the actual patch :-) As for implementation, please add the functions to the core part, not the GUI (just for completeness). As for CVSS itself, do you have a use-case for its usage? Esp. when it comes to establish and maintain the Environmental Score part (if we're talking about CVSS3), which might diffucult.

lucasnetau commented 6 years ago

In terms of use case the CVSS3 score gives us a value on which to priorities across different distributions. I have been using Tags with the Critical/Importing impacts from RedHat which is our primary distribution however this doesn't help with Debian/Ubuntu systems. My security team usually initially work off CVE CVSS scores when advisories are released.

To implement this so far I have done the following, most of the work is done to Dao/Manager/Model classes in core: 1) Modified Cve database table and added columns for cvssScore and cvssMetrics, this allows us to import either CVSSv3 and CVSSv2 score and vector string for each CVE from https://nvd.nist.gov/vuln/data-feeds#JSON_FEED (I have also used the RedHat Security Data feed which we use to generate the Tag XML), this is done via a cli import script similar to the vds sync process.

2) The CVSS score and vector string are displayed under the CVE header on cve.php, the vector string is linked to the https://nvd.nist.gov CVSS v2/v3 calculators to provide more information to the end user.

3) Modified Host database table and added a highestCvssScore column. calculateVulnerabilities is modified to also calculate the highest CVSS score for all vulnerable packages for each host.

These two items are in development: 4) Modified hosts.php to show the max CVSS score for each host in the table

5) Modified host_cves.php to show the CVSS score after each CVE name in the table eg. "CVE-2018-3333 (5.6)" to help spotting what package may need to be updated immediately.

BTW, What is the reasoning behind the xml import for CveTags? Is there some system you use to produce these?

kouril commented 6 years ago

On Fri, Sep 21, 2018 at 04:51:01AM -0700, lucasnetau wrote:

In terms of use case the CVSS3 score gives us a value on which to priorities across different distributions. I have been using Tags with the Critical/Importing impacts from RedHat which is our primary distribution however this doesn't help with Debian/Ubuntu systems. My security team usually initially work off CVE CVSS scores when advisories are released.

I see thanks. We used to use the RedHat tags in the past but found them linked with one particular environment (machines with limited numbers of users), which was not covering ours where we operate facilities with many users accounts. For instance kernel issues allowing for (local) privilege escalations are not rated very high by RedHat but these are really criticial for our environments.

To implement this so far I have done the following, most of the work is done to Dao/Manager/Model classes in core: 1) Modified Cve database table and added columns for cvssScore and cvssMetrics, this allows us to import either CVSSv3 and CVSSv2 score and vector string for each CVE from https://nvd.nist.gov/vuln/data-feeds#JSON_FEED (I have also used the RedHat Security Data feed which we use to generate the Tag XML), this is done via a cli import script similar to the vds sync process.

2) The CVSS score and vector string are displayed under the CVE header on cve.php, the vector string is linked to the https://nvd.nist.gov CVSS v2/v3 calculators to provide more information to the end user.

3) Modified Host database table and added a highestCvssScore column. calculateVulnerabilities is modified to also calculate the highest CVSS score for all vulnerable packages for each host.

These two items are in development: 4) Modified hosts.php to show the max CVSS score for each host in the table

5) Modified host_cves.php to show the CVSS score after each CVE name in the table eg. "CVE-2018-3333 (5.6)" to help spotting what package may need to be updated immediately.

What you described sounds reasonable, thanks a lot for the contribution.

Perhaps one thing - please keep the GUI usable also for installations that don't want to add the CVSS scores.

BTW, What is the reasoning behind the xml import for CveTags? Is there some system you use to produce these?

We mark some CVE with custom tags based on assessment by our vulnerabity team, these tags may be shared with other Pakiti servers monitoring other parts of our constituency (we're organized in a hierarchy). In practice it's now used to keep our production and development servers in sync.

Daniel

bluikko commented 4 years ago

I have been looking into something similar. I only have EL machines here so I am talking about Red Hat VDS only. I hope it could be similar for other OS and I hope I am not missing some already existing functionality that I did not know was there...

The Red Hat VDS already provide the overall severity like Critical/High/Moderate/Low in the "severity" attribute, which in the database can be seen in table cvedef column title, for example:

RHSA-2010:0860: samba security update (Critical)

Full CVSS scoring would be absolutely great but is a larger effort. At minimum (in my opinion) the severity should be easily visible somehow. For example:

I do not know if I have time to start implementing this - it would be a long project in any case due to my time constraints. But I would not wish to start if someone else is already working on a better implementation.

So, @kouril @lucasnetau do you have any updates since the discussion in Sep 2018?

Edit: I wanted to add that in my opinion Pakiti has incredible potential. It is to my knowledge the only open source patch tracking system there is. It works very well (usually) but lacks polish and some more advanced features like these would be extremely useful. I am very surprised that Pakiti does not get more attention - perhaps it is a combination of being very low-key and "rough" so that people aren't attracted to it?