CloudPassage Halo — 22 October 2014 Release
The 22 October 2014 Release of CloudPassage® Halo® features a new organizational structure for server groups, improves the functionality of several configuration rule checks, provides the ability to retrieve vulnerability exceptions through the Halo REST API, and includes other new features and improvements to both Halo and the Halo REST API.
New Features and Improvements
Server-group organizational changes
On the Halo portal dashboard page, the names of certain server groups have changed. Also, an organizational relationship has been established among the groups.
- What has been called the "Unassigned" group is now the root group for all of a customer account's server groups, and its default name is the same as the company name on the account. All newly-created server groups will be child groups of the root group.
- For an existing account, the policies and servers of the previous "Unassigned" group are retained in the root group, and the existing customer-created groups are considered child groups of the root group.
- The "All Servers" category no longer exists. Servers that would previously have been added to "All Servers" (for example, servers without a defined server tag) are now assigned to the root group
- In the Halo portal, you can manipulate the root group in the same way as other groups—you can rename it, assign and remove policies, and define a server tag for it, and move servers into or out of it.
- The Halo dashboard display for the root group shows the total critical and non-critical issues for the root group alone. Likewise, the list of servers includes only those servers that are in the root group itself.
- The dashboard display for each group displays the total number of servers (active, deactivated, and missing) in the group, in parentheses following the group name.
Expanded capabilities for Windows configuration rule checks
Support for domain usernames added to Local User Rights Assignment rule check
Previously, the Local User Rights Assignment configuration-policy rule check did not accept input of special characters, including "@" and" \", for usernames in the Security Settings field. This had the effect of disallowing the specification of domain user account names in the field.
Those particular special characters are now supported, and domain user account names can be specified in the check.
Support for commas added to Registry Key Value Settings check
Previously, the Registry Key Value Settings configuration-policy rule check could not support value settings that included commas, because the comma was interpreted as a separator between two values.
As a workaround for this issue, you can escape any internal commas with a backslash (as in "\,") to ensure that Halo will not consider them to be separators.
Support for empty values added to Registry Key Value Setting check
Previously, the Registry Key Value Setting configuration-policy rule check did not accept an empty input value for the Expected Data field.
The behavior of this check has changed, so that now you can leave the field blank if you want the check to verify that the setting for the specified registry value is empty.
Enhancements to the Halo REST API
New CVE exceptions endpoint added to Halo API
The Halo REST API now incudes an API endpoint that allows clients to obtain a list of defined exceptions to detected vulnerable packages. The endpoint is named "CVE Exceptions" and has this object URL:
The endpoint supports GET calls that allow you to retrieve all defined exceptions in the environment or a single exception specified by ID.
Pagination capability added to all API methods that return a list of items
The ability to obtain paginated JSON results for GET calls that return lists of items has been extended to all calls that return a list. The pagination capability is described under Pagination of Results in the Halo REST API Developer Guide.
Other new features and improvements
Sparkline graphs removed from server summary page
For improved loading performance of the Halo portal Server Summary page (accessed by clicking the name of a server on the Dashboard page), the small "sparkline" graphs beneath the count of critical and non-critical issues for each module have been removed. For example, for software vulnerability the summary display now looks like this:
The sparkline graphs are still available, though; clicking the More detail link on that page brings up the scan results page, which continues to display them:
Special events policy: corrected functionality for "Apply to all" checkboxes
On both the Edit Special Events Policy page and the Edit Alert Profile page, the functionality of the Apply to All checkboxes at the tops of the Non-critical, Critical, and Generate alert columns has been corrected.
Previously, if any of those checkboxes had been clicked previously, any second or subsequent clicks were non-functional. The boxes now function correctly on any click.
The following issues are among those that remain unresolved as of this release. Any known workarounds are described.
- IE8 not supported for Halo reporting. The Halo reporting service does not function for a user who has logged into Halo using Internet Explorer 8.
Workaround: Log in with a more recent version of IE or with a different browser, or use the Halo API to construct server searches.
- Editing file integrity baseline expiration. If you want to change the expiration value when editing or re-baselining an existing baseline, the new expiration date is now calculated from the current date, rather than from the original baseline-creation date. However, if you keep the same setting (number of days) for the expiration value, the re-calculation does not occur and the expiration date remains based on the original creation date.
Workaround: Select a different expiration value and save the baseline. Then re-edit the baseline and specify your desired expiration value.
- False-positive file integrity security events can occur in Linux systems in which the
prelinkutility regularly resolves links to dynamic libraries in executable files and stores the results in the executable files, thereby modifying them. This action can create differences between the servers of a scan group and the baseline (golden master) server, thereby causing the false positives.
Workarounds. Take either of the following steps:
- Manually run
prelinkon the baseline server before running the baseline scan. That should eliminate most or all false security events related to
- Turn off pre-linking on all of your servers.
- Manually run