Updating vulnerability detector documentation with scan type details #3540

pereyra-m · 2021-03-03T19:44:03Z

Description

This PR describes more in detail the current Vulnerability Detector process and also describes different aspects from the new CVEs table.

Checks

It compiles without warnings.
Spelling and grammar.
Used impersonal speech.
Used uppercase only on nouns.

DProvinciani

Please, apply changes according to the comments.

DProvinciani · 2021-03-03T20:14:35Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+Scan types
+==========
+
+The results are presented as alerts and also stored in a database. You can check the last scan alerts, or query each agent's individual CVEs DB.


I suggest moving this to the end of the previous paragraph.

With this little reword for the second sentence: So you can check the last scan alerts, or query every single agent's database of CVEs.

You are right, it has more sense above. But I tried to mix the second sentence you proposed with another suggestion.
Please, look at it and tell me.

DProvinciani · 2021-03-03T20:16:37Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+
+The results are presented as alerts and also stored in a database. You can check the last scan alerts, or query each agent's individual CVEs DB.
+
+The Vulnerability Detector module can run a scan on startup (**run_on_start** option) and with a fixed frequency (**interval**).


Can we set run_on_start and interval as linked references to the settings?

All references to configuration parameters now are links too.

DProvinciani · 2021-03-03T20:19:42Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+The results are presented as alerts and also stored in a database. You can check the last scan alerts, or query each agent's individual CVEs DB.
+
+The Vulnerability Detector module can run a scan on startup (**run_on_start** option) and with a fixed frequency (**interval**).
+In any of these cases, the packages that have been already scanned will wait until the **ignore_time** expires to be re-scanned.


Does the new line break the paragraph? If so, I suggest making the lines 27, 28, and 29 a single paragraph.

Only empty lines create new paragraphs. Those three lines already are together.

DProvinciani · 2021-03-03T20:20:47Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+
+The Vulnerability Detector module can run a scan on startup (**run_on_start** option) and with a fixed frequency (**interval**).
+In any of these cases, the packages that have been already scanned will wait until the **ignore_time** expires to be re-scanned.
+This results in a better performance and we avoid a repeated alert during a configurable time. We have then two different type of scans


Please, add colon : at the end of two different type of scans.

DProvinciani · 2021-03-03T20:28:34Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+In any of these cases, the packages that have been already scanned will wait until the **ignore_time** expires to be re-scanned.
+This results in a better performance and we avoid a repeated alert during a configurable time. We have then two different type of scans
+
+- Partial scans: only new packages are scanned, as long as **ignore_time** is still valid


I suggest changing the order. First, explain the full scans, and then the partial scans.
Another thing. Should the first word after the colon make use of capital letters? I mean, Only and The.

The order has been inverted and the capital letter were used.

DProvinciani · 2021-03-03T20:28:53Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+This results in a better performance and we avoid a repeated alert during a configurable time. We have then two different type of scans
+
+- Partial scans: only new packages are scanned, as long as **ignore_time** is still valid
+- Full scan: the first scan of an agent always is complete. But then, only when the **ignore_time** passes the module scans all available packages again


I would reword this explanation in this way. The first time, Vulnerability Detector scans every single package installed. But then, only when the configured **ignore_time** expires, the module will scan all the available packages again.

I've made the reword you suggest, but the passive voice seem to me more adequate. And the "module" word becomes unnecessary in that case.

Please, take a look at it and tell me.

DProvinciani · 2021-03-03T20:30:18Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+
+There are few considerations that arise from this behavior
+
+- Every full scan generates alerts for all packages, so the alerts are repeated until they get fixed


I would say for all the packages

DProvinciani · 2021-03-03T20:31:41Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+- Partial scans: only new packages are scanned, as long as **ignore_time** is still valid
+- Full scan: the first scan of an agent always is complete. But then, only when the **ignore_time** passes the module scans all available packages again
+
+There are few considerations that arise from this behavior


There is an inconsistency at the end of each item. Some of them finalize with a dot . and other ones not.

Now every item has a dot at the end.

DProvinciani · 2021-03-03T20:32:14Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+There are few considerations that arise from this behavior
+
+- Every full scan generates alerts for all packages, so the alerts are repeated until they get fixed
+- The user can't trigger a full scan manually, the only option is to decrease the **ignore_time** option


I would say decrease the **ignore_time** setting

DProvinciani · 2021-03-03T20:33:32Z

source/user-manual/reference/ossec-conf/vuln-detector.rst

@@ -76,14 +76,17 @@ Runs updates and vulnerabilities scans immediately when service is started.
 ignore_time
 ^^^^^^^^^^^^

-Time during which vulnerabilities that have already been alerted will be ignored.
+Time during which vulnerabilities that have already been alerted will be ignored. When this time hasn't passed yet, only partial scans will be performed.


Probably we could add a linked reference to partial scans.

The Scan types section was referenced.

palaciosjeremias · 2021-03-03T20:34:48Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+Scan types
+==========
+
+The results are presented as alerts and also stored in a database. You can check the last scan alerts, or query each agent's individual CVEs DB.


I think CVEs DB can be confused with the general CVE database.
We can refer to this as:
Vulnerable Software (vuln_cve) table on each agent's individual DB

You are right, but this sentence had other suggestions too.

Please, check the new version and tell me.

palaciosjeremias · 2021-03-03T20:37:51Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+
+The results are presented as alerts and also stored in a database. You can check the last scan alerts, or query each agent's individual CVEs DB.
+
+The Vulnerability Detector module can run a scan on startup (**run_on_start** option) and with a fixed frequency (**interval**).


Maybe we can replace "with a fixed frequency" with " every defined period of time"

The "fixed frequency" term was replaced with "period of time", but I also added the "arbitrary" word.
Please, take a look at it and tell me.

palaciosjeremias · 2021-03-03T20:42:22Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+This results in a better performance and we avoid a repeated alert during a configurable time. We have then two different type of scans
+
+- Partial scans: only new packages are scanned, as long as **ignore_time** is still valid
+- Full scan: the first scan of an agent always is complete. But then, only when the **ignore_time** passes the module scans all available packages again


Maybe we can replace "But then," with "After that, a complete scan occures"

You are right, "But then" is not the most accurate connector.
Nevertheless, I propose using "From then on".
Please, give me your opinion.

palaciosjeremias · 2021-03-03T20:43:58Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

+
+The Vulnerability Detector module can run a scan on startup (**run_on_start** option) and with a fixed frequency (**interval**).
+In any of these cases, the packages that have been already scanned will wait until the **ignore_time** expires to be re-scanned.
+This results in a better performance and we avoid a repeated alert during a configurable time. We have then two different type of scans


We should add the final dot in this line and others below.

palaciosjeremias · 2021-03-04T12:21:04Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

-The Vulnerability Detector module can run a scan on startup (**run_on_start** option) and with a fixed frequency (**interval**).
-In any of these cases, the packages that have been already scanned will wait until the **ignore_time** expires to be re-scanned.
-This results in a better performance and we avoid a repeated alert during a configurable time. We have then two different type of scans
+The Vulnerability Detector module can run a scan on startup (:ref:`run_on_start <vuln_det_run_on_start>`) and every certain arbitrary period of time (:ref:`interval <vuln_det_interval>`).


I think arbitrary makes the reader think it's a random time. Maybe we should use i.e. configurable.

Or, to avoid the duplication in the line below, we can just remove arbitrary or replace it with desired or adjustable

The arbitrary word has been removed.

DProvinciani

Looks good!

DProvinciani · 2021-03-04T12:35:07Z

source/user-manual/capabilities/vulnerability-detection/how_it_works.rst

@@ -18,3 +18,32 @@ The global vulnerability database is created automatically, currently pulling da
 This database can be configured to be updated periodically, ensuring that the solution will check for the very latest CVEs.

 Once the global vulnerability database (with the CVEs) is created, the detection process looks for vulnerable packages in the inventory databases (unique per agent). Alerts are generated when a CVE (Common Vulnerabilities and Exposures) affects a package that is known to be installed in one of the monitored servers. A package is labeled as vulnerable when its version is contained within the affected range of a CVE.
+The results are presented as alerts and also stored in a database. So you can check the last scan alerts, or query every single agent's Vulnerable Software DB.


Vulnerable Software shouldn't be with capital letters.

Updating vulnerability detector documentation with workflow details

0d73b68

pereyra-m added this to the Sprint 125 - Core/Bugman milestone Mar 3, 2021

pereyra-m requested review from DProvinciani, palaciosjeremias and MiguelazoDS March 3, 2021 19:44

pereyra-m self-assigned this Mar 3, 2021

pereyra-m linked an issue Mar 3, 2021 that may be closed by this pull request

Add the capability to know which CVE’s affect an agent - Documentation #3533

Closed

DProvinciani suggested changes Mar 3, 2021

View reviewed changes

DProvinciani added the module/vuln detector label Mar 3, 2021

palaciosjeremias reviewed Mar 3, 2021

View reviewed changes

DProvinciani changed the title ~~Updating vulnerability detector documentation with scan type details~~ Add the capability to know which CVE’s affect an agent - Documentation changes Mar 3, 2021

DProvinciani changed the title ~~Add the capability to know which CVE’s affect an agent - Documentation changes~~ Updating vulnerability detector documentation with scan type details Mar 3, 2021

DProvinciani removed a link to an issue Mar 3, 2021

Add the capability to know which CVE’s affect an agent - Documentation #3533

Closed

DProvinciani linked an issue Mar 3, 2021 that may be closed by this pull request

Add vulnerability detector scan type details to the Wazuh documentation #3541

Closed

Improving vulnerability detector section with review comments

4ca509e

palaciosjeremias approved these changes Mar 4, 2021

View reviewed changes

DProvinciani approved these changes Mar 4, 2021

View reviewed changes

pereyra-m added 2 commits March 4, 2021 11:28

Correcting minor typos

b4dd346

Updating vulnerability detector scan types diagram

3568046

DProvinciani merged commit 2e63b8c into dev-cves-by-agent Mar 5, 2021

DProvinciani deleted the 3533-cves-by-agent-docu branch March 5, 2021 14:30

DProvinciani mentioned this pull request Mar 5, 2021

Add vulnerability detector scan type details to the Wazuh documentation #3541

Closed


		The results are presented as alerts and also stored in a database. You can check the last scan alerts, or query each agent's individual CVEs DB.

		The Vulnerability Detector module can run a scan on startup (run_on_start option) and with a fixed frequency (interval).


		There are few considerations that arise from this behavior

		- Every full scan generates alerts for all packages, so the alerts are repeated until they get fixed

Updating vulnerability detector documentation with scan type details #3540

Updating vulnerability detector documentation with scan type details #3540

Conversation

pereyra-m commented Mar 3, 2021

Description

Checks

DProvinciani left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

DProvinciani left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment