Greenbone-Produkte: Roadmap & Lifecycle

Greenbone OS: Unterstützte Versionen

Version
Greenbone OS 20.08
Lifecycle-Status New
End of Life 30.11.2021
Patch-Level 20.08.6 (30.11.2020)

Greenbone OS Lifecycle-Status:

Januar 2021

Greenbone Security Manager Lifecycle-Status:

Januar 2021

Greenbone-Changelog

 

2020-08-31: Greenbone OS 20.08

Aktuellster Patch-Level: 20.08.6 (2020-11-30)

Lifecycle-Phase: New

20.08.6 (2020-11-30):

  • Greenbone OS:
    • Extension: Alerts and Schedules are now available on the GSM ONE (#152653).
    • Improvement: The gvm-tools included in GOS were updated to version 20.10.1 (#150912).
    • Improvement: To prevent problems, major GOS upgrades are no longer possible if there is not enough storage space left for the database migration (#147578).
    • Improvement: If the Greenbone Feed Signing Key, which is required for the validation of GOS upgrades, is expired, upgrades are no longer possible instead of failing. For a solution, contact Greenbone Networks Support (#93687, #148007).
    • Bugfix: During a master-sensor feed update, not all NVTs were updated on the sensor in some cases (#150662, #2020101910000051).
    • Bugfix: The GOS system integrity check could report a false positive warning after a GOS backup was restored (#147070).
    • Bugfix: The LCD display service could sometimes fail on GSM models 5300 und 6400 (#136798, #2020032710000049).
    • Bugfix: During the first time setup wizard, the feed server is no longer contacted twice in rapid succession. This could cause problems in combination with the Greenbone Community Feed server. Users of the Greenbone Security Feed Server were not affected (#120005).
    • Bugfix: SSH keys of the types ‚rsa-sha2-256‘ and ‚rsa-sha2-512‘ are now supported (#150121, #2020101910000069).
    • Minor bugfix: The spelling and usability of the GOS administration menu have been improved (#101818, #103537, #123181, #144657, #150664, #2019062610000057).
    • Minor bugfix: Uninstalling the gsm-debug meta-package did not uninstall all contained packages (#147286).
    • Minor bugfix: The collected service could generate excessive, but harmless log messages (#68977).
    • Minor improvement: The full GOS version including the current patch level is now shown on the GOS login screen (#116817).
    • Minor improvement: If no SSH host keys exist, they will now be re-created when enabling the SSH service (#149548).
    • Minor improvement: A command line setting to configure the timeout of SCP alerts has been added (#144727).
    • Minor improvement: Help texts have been added for running the GOS integrity check via the command line (#146804).
    • Minor improvement: All files included in the Greenbone Support Package are now non-hidden by default (#81612).
    • Minor improvement: The GSM manual included in GOS was updated to the current version from 2020-11-30 (#152775).
  • Vulnerability Management:
    • Improvement: The alert condition ‚[Filter] matches at least [x] result(s) NVT(s)‘ has been added (#148607, #2020092310000036).
    • Improvement: When editing a ‚Username + SSH Key‘ credential, the correctness of the password is now verified (#112159).
    • Bugfix: Deleting and then re-downloading a scan config that had all NVTs of a family selected, e.g. ‚Full and very deep‘, caused that family to have no NVTs selected (#150579, #2020102210000053, #2020102610000019)
    • Bugfix: If a IP addresses of target hosts were configured with a leading zero in an octet, e.g. ‚192.168.50.010‘, the maximum number of hosts was calculated incorrectly, and vulnerability scans could fail (#151801, #2020111010000029).
    • Bugfix: If a target credential cannot be decrypted, an unauthenticated vulnerability scan without a credential will now be run against the target. Previously, the scan would remain in the status ‚Requested‘ indefinitely (#149549).
    • Bugfix: For SCP alerts the handling of usernames and destination paths has been improved in combination with Windows systems. In addition, a configurable timeout has been introduced for the SCP alert to prevent it from running indefinitely in some situations (#144727, #2020071610000044).
    • Bugfix: It was not possible to delete a web user, if the user owned TLS certificates, and no inheriting user was provided (#149652, #2020101410000078).
    • Bugfix: When deleting a web user, web interface settings will no longer be inherited. This will prevent settings of the inheriting user from being overwritten (#149652, #2020101410000078).
    • Bugfix: It was not possible to delete orphaned permissions in all cases (#150186, #2020102110000019).
    • Bugfix: The verification of ports and port ranges when editing a port list has been improved (#149776).
    • Bugfix: The ’scan_nvt_version‘ XML tag in XML reports was empty erroneously (#150569, #2020102210000071).
    • Bugfix: Moving a data object via feed scan config or policy to the trashcan generated excessive, but harmless log warnings (#149299, #2020100710000046).
    • Bugfix: Two SQL errors that could occur when rebuilding the SCAP or CERT databases have been fixed (#151175).
  • Vulnerability Scanning:
    • Bugfix: If a host name in a list of target hosts could not be resolved, scans could fail with the status ‚Interrupted‘ (#150988, #2020102810000033).
    • Bugfix: When configuring a target IP with a subnet mask of less than /24, addresses ending in ‚.0‘ are now supported (#150990).
    • Bugfix: When the host name resolution of a target resolved it to more than one IP address, the scan progress bar percentage could show ‚100%‘ even though the scan was still in progress (#149349).
    • Bugfix: For scans with a SNMP credential, the SNMP community ‚None‘ was erroneously used when configuring no community. An empty string is now used to assure that no community will be used (#149649).

20.08.5 (2020-10-15):

  • Greenbone OS:
    • Bugfix: Activating DHCPv6 could cause an error (#149180).
    • Bugfix: GOS upgrades did not stop as expected, if the packages to be upgraded could not be verified. An empty upgrade was applied in this case (#149212).
    • Bugfix: Vulnerability scans could erroneously show missing ‚iTLB multihit‘ Linux kernel mitigations for GOS. Since no virtualization is in use, the system was and is always protected by the kernel unconditionally (#146845).
    • Minor bugfix: During feed updates, cosmetic known hosts warnings for the IP address ‚172.30.2.22‘ appeared (#146729, #2020100210000028)
    • Minor improvement: The postgres database migration during GOS upgrades has been improved (#148526).
    • Minor improvement: To prevent problems, major GOS upgrades are no longer possible if a global gateway is used, but no global gateway interface is configured (#147418).
    • Minor improvement: The warning text displayed if a GOS upgrade is blocked has been updated (#148006).
    • Minor improvement: The GSM manual included in GOS was updated to the current version from 2020-10-15 (#149706).
  • Vulnerability Management:
    • Bugfix: The Scans > Vulnerabilities page in the web interface could fail to load due to an error (#143484).
    • Bugfix: A database deadlock could occur if changing the feed import owner and browsing scan results at the same time (#146803).
    • Bugfix: The ‚Auto Delete Reports‘ functionality did not work on GSM models that do not support schedules (#133136, #2020020310000041).
    • Bugfix: The advanced task wizard in the web interface no longer offers to create a schedule on GSM models that do not support schedules (#147660, #2020091010000122).
    • Bugfix: The number of hosts shown per operating system on the Assets > Operating Systems page included operating systems for which the user did not have permissions to view (#140467).
    • Bugfix: When changing the name or comment of a scan configuration or a policy that was in use, an erroneous warning was displayed (#120605, #147669).
    • Bugfix: Filters attached to SecInfo alerts could not be edited and saved (#109311, #2020081710000022, #202008171000002).
    • Bugfix: The placeholder ‚$U‘ did not work for e-mail alerts (#148533, #2020092310000036).
    • Bugfix: Saving invalid values for the ‚Rows Per Page‘ setting in the ‚My Settings‘ menu is now prohibited, and corresponding tooltips have been implemented (#148529).
    • Bugfix: The deprecated ‚SecInfo‘ filter setting has been removed from the ‚My Settings‘ menu (#149179, #2020100510000031).
    • Bugfix: TLS certificates from container tasks, or belonging to other users, could not be downloaded even with permissions (#148892, #2020092810000081).
    • Bugfix: TLS certificates downloaded via the web interface could not be re-uploaded via the API (#125191).
    • Minor improvement: The tooltip for override indicators on result details pages in the web interface has been improved (#146799).
  • Vulnerability Scanning:
    • Bugfix: SNMPv3 authentication for vulnerability scans failed, if no SNMP community was configured, even though the SNMP community is not relevant for SNMPv3 (#148611).
    • Bugfix: Vulnerability scans failed, if a scan configuration or policy without any NVT preferences was used (#148894).
    • Minor improvement: The error handling for WMI queries has been improved. Previously the logging was too verbose and included events that were not errors, but expected behaviour (#125438).

20.08.4 (2020-09-23):

  • Greenbone OS:
    • Extension: The former ‚Greenbone Community Edition‘ virtual appliance has been updated to GOS 20.08 and renamed to ‚GSM TRIAL‘ (#148403).
    • Bugfix: Virtual GSM appliances with EFI/UEFI boot mode could fail to boot after being exported or cloned (#148262).
    • Bugfix: The ‚GSM Installation and Rescue‘ GRUB option did not boot the GOS installer as expected (#148530).
    • Bugfix: The USB power management on GSM hardware appliances could consume excessive CPU time (#147583).
    • Bugfix: The verification of a downloaded flash image would always fail (#147878).
    • Bugfix: Sensor scans via a proxy could fail for OSP sensors (#147582).
    • Minor bugfix: The GOS version was not displayed correctly in the GOS installer (#147658).
    • Minor improvement: The database-vacuum script that is used to reclaim storage space has been updated (#148266).
    • Minor improvement: The description of the ‚Setup > Services > SNMP‘ menu has been extended, it now includes a warning that saving SNMP configuration changes will stop all running scans (#148479).
    • Minor improvement: A warning has been added when using the command ’su‘ incorrectly in the Greenbone OS command line administration (#147666).
    • Minor improvement: The GSM manual included in GOS was updated to the current version from 2020-09-22 (#147872).
  • Vulnerability Management:
    • Improvement: For Compliance Audits, the base colouring of all non-compliant audit status has been adjusted to red. This way, non-compliant audits can be identified much quicker, for example, a 0% compliant audit status will now be always shown in red (#147577).
    • Bugfix: When editing and saving scan configurations or compliance policies, the names of some included NVT preference options were not saved correctly (#147870).
    • Minor bugfix: On Schedule and Report Format details pages in the web interface, the ‚Move to trashcan‘ button was incorrectly shown as a ‚Delete‘ button (#147936).
  • Vulnerability Scanning:
    • Improvement: Experimental TLS 1.3 support has been enabled for the OpenVAS vulnerability scanner (#145963).
    • Improvement: Experimental SNMPv3 support has been enabled for the OpenVAS vulnerability scanner (#57662).
    • Bugfix: Stopping a vulnerability scan could fail in some cases (#147124).

20.08.3 (2020-09-10):

  • Greenbone OS:
    • Bugfix: GOS could not be installed with EFI/UEFI boot mode on VirtualBox 6.1.14 or later (#147300).
    • Bugfix: If no network interface as assigned to the global gateway, upgrades from GOS 6.0 failed (#147215, #2020090410000018, #2020090710000012, #2020090710000067, #2020090710000101).
    • Bugfix: The package ncat was erroneously removed when upgrading to GOS 20.08 (#147574).
    • Bugfix: Feed updates via proxy could fail on GSM models 35 and 25V (#147437).
    • Bugfix: Removed an unnecessary menu option to configure the sensor protocol for GSM modes 35 and 25V. These appliances will always use the OSP protocol (#147301).
    • Minor bugfix: Reduced the amount of error messages when the feed import owner had been set, but no feed was present on the system. These error messages were expected and are harmless (#147303).
    • Minor improvement: The GSM manual included in GOS was updated to the current version from 2020-09-10 (#147570).
  • Vulnerability Scanning:
    • Bugfix: Only the default alive test method was applied (#147302, #2020090810000038).

20.08.2 (2020-09-07):

  • Greenbone OS:
    • Extension: EFI/UEFI boot mode has been implemented for all virtual GSM appliances shipped with GOS 20.08.2 or later (#147079).
    • Improvement: The GOS upgrade functionality has received several internal improvements and fixes (#147130).
    • Minor improvement: The GSM manual included in GOS was updated to the current version from 2020-09-07 (#147129).

20.08.1 (2020-09-03):

  • Greenbone OS:
    • Bugfix: The settings ‚Management IP (v4)‘ and ‚Management IP (v6)‘ were not applied (#147079).
    • Bugfix: GOS upgrades no longer fail if the system integrity is compromised. However, after the upgrade, a system integrity warning will be displayed (#147125).
    • Minor improvement: The GSM manual included in GOS was updated to the current version from 2020-09-03 (#146861).
  • Vulnerability Management:
    • Bugfix: When importing scan configurations or compliance policies, the included NVT preferences were not imported correctly in all cases (#146855).
  • Vulnerability Scanning:
    • Bugfix: In rare cases stopping a scan task could cause system instability (#146802).

20.08.0 (2020-08-31):

  • Scan Queueing: To prevent scans from overloading the system and from starting at an inappropriate time (e.g., during a feed update), a scan queue management has been introduced. Scan tasks are only started if sufficient system resources are available. The available resources depend on the GSM model, the GOS version used, and the current workload of the system. If too many tasks are started and running at the same time and not enough resources are available, scans are added to a waiting queue. A new status bar „Queued“ has been introduced.
  • Performance Improvements: Due to scan queueing as well as other architecture improvements, the number of scans that can be run simultaneously has been increased in GOS 20.08 when compared to GOS 6.0. On a GSM 400 we measured more than twice the capacity with GOS 20.08 in comparison to GOS 6.0.
  • Data Objects via Feed: With GOS 20.08, scan configurations, compliance policies, report formats, and port lists by Greenbone Networks will be distributed via the Greenbone Security Feed. This allows for direct updates of existing objects, and for the publication of new scan configurations, compliance policies, etc. for current, hot NVTs. In addition, users will not need to manually download additional files from the Greenbone website anymore.
  • Beaming: Beaming makes it possible to copy the current state of a GSM to another GSM. The data may be transferred directly and securely from one GSM to another, or it may be saved for a later transfer. The data includes all user data (e.g., tasks, reports, results) and – optionally – system settings, i.e., the GOS configuration. Beaming makes it much easier to upgrade from one GSM model to another while still keeping all previous data.
  • Business Process Map:The Business Process Map (BPM) can be used to illustrate the impact of collected scan results on a business. Each process has assigned hosts and will be highlighted based on the highest severity of these hosts. This way, it is possible to see the vulnerability of processes and their impact on any linked processes at a glance, determining the risk to the company based on the location of a host within the process chain.
  • Updated Feed Status Page: The feed status page of the web interface has received several improvements. The status of the objects that are distributed via the feed (scan configurations, compliance policies, port lists and report formats) is now included in the table. In addition, the feed status page now shows if a feed update is in progress.
  • Start Task via „New SecInfo“ Alert: Starting a task automatically after a feed update is now possible. This feature unlocks the combination of a „New NVTs/CVEs/CPEs…“ alert event and the „Start Task“ alert method in the web interface.
  • GOS Backup Compatibility Checks: The Greenbone Operating System (GOS) now checks whether a backup is suitable before restoring the backup. Unsuitable backups cannot be restored, and warnings may be displayed. This feature prevents errors when restoring backups.
  • Comprehensive Update of the Base System: For GOS 20.08, the underlying Linux foundation of GOS was updated to the latest version.

Lifecycle-System

 

Der Lebenszyklus eines Release von Greenbone OS folgt einem klaren Stufenplan. Dabei achten wir besonders auf:

  • die Stabilität eines einzelnen Release
  • bruchfreie und einfache Migrationspfade
  • einen komfortablen Zugang zum aktuellsten Stand unserer Technologie

Die Greenbone OS Lifecycle-Phasen

  • Planning: In der Planungsphase berücksichtigen wir unter anderem alle von Kunden eingebrachten Wünsche für neue oder erweiterte Funktionalitäten.
  • Development: Die neuen Funktionen sind teilweise schon implementiert, teilweise noch in Arbeit. Der endgültige Funktionsumfang liegt noch nicht fest. Sobald ein neues Release in diese Phase eintritt, erscheint es auf unserer Roadmap.
  • Alpha: Erste Versionen des neuen Greenbone OS werden erstellt und an eine interne Testgruppe verteilt. Es können noch weitere Funktionen aufgenommen werden, größere Änderungen müssten jedoch begründet werden.
  • Beta: Der Funktionsumfang liegt fest. Das neue Greenbone OS wird einem erweiterten Kreis, darunter auch ausgewählten Partnern und Kunden, zur Verfügung gestellt.
  • New: Die Freigabe für den ersten GSM ist erfolgt, die neue Version ist aber noch nicht für alle GSMs verfügbar. Die Freigabe für die verschiedenen GSMs erfolgt schrittweise. Das neue Release wird aus der Roadmap herausgenommen und erscheint unter Betriebssystem Greenbone OS.
  • Mature: Die Freigabe für Migrationen von älteren Releases ist erfolgt.
  • End of Life: Sobald ein Datum für das Lebensende bekannt gegeben wurde, befindet sich das Release in der End-of-Life-Phase. Anwender sollten spätestens jetzt mit dem Wechsel auf ein neueres Release beginnen.
  • Retired: Das Lebensende wurde erreicht. Möglicherweise liegt eine solche Version aber noch auf einem Flash vor und wird durch einen Factory-Reset wieder aktiviert. Dann wird die Aktualisierung auf das neue Release noch unterstützt. Das Release wird nun aus unserer QA entlassen, d. h. die permanent mitlaufenden QA-Systeme werden abgeschaltet. Das Release wird aus der Liste aktueller Releases herausgenommen und in das Archiv verschoben.
  • Obsolete: Es gibt keinerlei Unterstützung mehr.

Greenbone OS Lifecycle-Ebenen

  • Patch-Level: Mit der letzten Nummer in einer GOS-Version benennen wir den Patch-Level, z. B. „21“ bei „3.0.21“.
    Vor GOS 3.0 wurde der Patch-Level mit einem Bindestrich angehängt, wie beispielsweise „2.0.0-21“. Innerhalb eines Release wird immer der aktuellste Patch-Level voll supported. Für alle vorherigen Patch-Level wird die Aktualisierung auf den aktuellen Stand unterstützt.
    Im Rahmen von Patch-Level-Aktualisierungen werden keine Änderungen vorgenommen, die das voreingestellte Verhalten ändern. Es werden auch keine größeren Funktionsänderungen eingeführt. Informationen zu den neuesten Patch-Levels werden über den Newsletter und über die Seite Upgrades zur Verfügung gestellt.
    Die Aufgabe von Patch-Level-Aktualisierungen sind Fehlerbeseitigungen sowie kleine Funktionsergänzungen, sofern sie keine Migration erfordern oder API-Änderungen bedeuten. Ebenso werden Sicherheits-Upgrades von Greenbone OS über Patch-Level eingepflegt.
    Patch-Level-Aktualisierungen sind einfach durchzuführen. Für Support-Tickets ist es sinnvoll, den Defekt auf Basis des aktuellsten Patch-Levels zu dokumentieren.
    Die Zählung der Patch-Level beginnt bei 0. Der erste Patch-Level eines neuen Release (beispielsweise „3.0.0“) ist die erste Alpha-Version. Bevor ein neues Release die Kunden erreicht, ist der Patch-Level-Zähler also bereits fortgeschritten.
  • Release: Mit der mittleren Nummer in einer GOS-Version benennen wir das Release, z. B. „0“ bei „3.0.21“.
    Innerhalb einer Generation werden alle Releases über einen längeren Zeitraum unterstützt. Sobald klar ist, dass das nächste Release auch die nächste Generation sein wird, erhält das letzte Release der Generation Langzeit-Unterstützung (LTS-Release). Der Support für die älteren Releases dieser Generation reduziert sich auf die Aktualisierung zum letzten Release. Beispielsweise ist GOS 2.2 ein LTS-Release, da nach diesem Release der Wechsel auf GOS 3.0 stattfand. Der Support für GOS 2.0 und GOS 2.1 läuft in diesem Fall früher aus.
    Das Lebensende eines Release wird grundsätzlich mindestens 3 Monate vor Ablauf bekannt gegeben, für ein LTS-Release mindestens 6 Monate. Der Newsletter weist regelmäßig auf entsprechende Fristen hin und der Status ist jederzeit auf der Seite Betriebssystem Greenbone OS einsehbar.
    Die Aufgabe von Releases ist die Einführung neuer Funktionen und die Erweiterung bestehender Funktionen, darunter durchaus auch Änderungen im voreingestellten Verhalten. Dies betrifft den Scanner selbst, die Web-Oberfläche, die API und die Administration. Die Aktualisierung des Flash-Systems bei hardwarebasierten GSMs ist für Releases in der Regel nicht notwendig. Migrationen der Datenbank sind überlicherweise zwingend notwendig und werden automatisch durchgeführt.
    Da der Wechsel größere Änderungen mit sich bringt, muss der Administrator einen Release-Wechsel explizit anweisen. Ist dies der Fall, läuft eine Release-Aktualisierung nach dem gleichen Prinzip wie eine Patch-Level-Aktualisierung ab.
  • Generation: Mit der ersten Nummer in einer GOS-Version benennen wir die Generation, z. B. „3“ bei „3.0.21“.
    Das Lebensende einer Generation erfolgt erst, wenn den Anwendern die Nachfolge-Generation sowie ein Flash-Upgrade mindestens seit einem Jahr zur Verfügung steht und eine Anleitung zur Aktualisierung und Migration erhältlich ist. Die Aufgabe einer Greenbone-OS-Generation ist die Einführung einer komplett neuen Basis, um den aktuellen Stand der Technik ohne Kompromisse für die Anwender nutzbar zu machen.
    In der Regel wird mit einer neuen Generation auch das Flash-Systeme einer GSM-Hardware aktualisiert.