CloudPassage Halo — 30 April 2014 Release
The 30 April 2014 Release of CloudPassage® Halo® includes new geolocation and whitelisting capabilities for configuration rule checks, improved navigation to server summary pages from the Halo Portal Dashboard, the ability for site administrators to delete Halo users, updates to the Scan History and File Integrity Policies endpoints in the Halo API, and other enhancements and fixes.
New Features and Improvements
Configuration Security Monitoring
New configuration rule check: Geolocation by Country
A new rule check has been added to Configuration Security Monitoring: Geolocation By Country. The check alerts you if any of your servers (Linux or Windows) has a connecting IP address whose geolocation is either (1) not on a list of permitted locations, or (2) on a list of prohibited locations.
You specify a desired (or undesired) location as a three-letter country code (ISO 3166-1 alpha-3). You can enter multiple codes as a comma-separated list.
Whitelisting added to Process Presence configuration rule check
A third option has been added to the Linux Process Presence rule check. In addition to the current "should be running" and "should not be running" options, you can now select "allowed to be running". If you submit a list of processes, that option functions as a whitelist: the check passes if any of the listed processes is running, and it fails if any process not on the list is running.
Context-sensitive help available for configuration checks
On the Edit Configuration Policy page, all forms for creating or editing a rule check now include a help link:
Clicking the link displays, in a separate window or tab, the online documentation describing that specific check (taken from the "Configuration Policy Rule Checks" appendix of Monitoring Server Configuration Security With CloudPassage Halo).
File integrity Monitoring
File integrity policy rules (targets) can be activated or deactivated
When creating or editing a file integrity policy, you can now specify the state (active or inactive) of any of the targets in the policy. Only active targets are scanned. Deactivating a target is a convenient way to temporarily remove it from the policy.
File integrity policy must have at least one active rule
A newly created or edited file integrity policy must have at least one active target; if the policy does not, Halo will not allow you to save it. Previously, the requirement was that there must be at least one rule, regardless of whether or not it is active.
File integrity events identify their source scan
On the Halo Portal's Security Events History page, a file integrity event generated during a scan (file integrity object signature changed, file integrity object missing, or file integrity object added) now includes a link to the scan that generated that event.
Larger set of acceptable characters in Linux firewall rule comments
Previously, the Halo Portal accepted only letters, numbers, spaces, periods, and underscores in the comments field of a firewall rule. Now, because iptables themselves are less restrictive, the Portal allows you to enter at least comma, #, @, :, /, and single and double quotes into your comments for Linux firewall rules.
The restrictions for Windows firewall rules are unchanged—only letters, numbers, spaces, periods, and underscores are permitted.
Changes to navigation links on Halo Dashboard pages
On the Halo Dashboard page, the following navigation changes have been introduced in this release:
- Clicking the name of a server in the list brings up the Server Summary page for that server. From the Server Summary page, you can follow links to view, for example, the Scan Results page or Details page for that server for any of the Halo modules (such as "Configs" or "Events") that you are interested in.
(Previously, clicking the name of the server on the Dashboard page brought up the Scan Results page or Details page for that server for the currently active Halo module.)
- On the Dashboard page with the "Firewall" module active, clicking the "Firewall Status" icon for a server brings up the Firewall Details page for that server.
- On the Dashboard page with the "Events" module active, clicking the number of critical or non-critical events for a server brings up the Security Events page for that server.
- On the Dashboard page with the "Configs", "access", "software", or "Integrity" module active, clicking the number of critical or non-critical events for a server brings up the Scan Results page for that server and module.
Now possible to delete Halo Portal users
Previously, a Halo site administrator could deactivate a Halo user on the Users tab of the Site Administration page of the Portal. Deactivated users cannot log into the Portal, although they continue to be listed on the Users tab, where the site administrator can re-activate them if desired.
To prevent a backlog of unwanted deactivated users from building up, the Portal now also allows the site administrator to permanently delete users. Deleted users cannot log in, they are not listed on the Users tab, and they cannot be recovered or re-activated. But they do remain in the Halo database for historical auditing purposes.
Additional filtering capability for Scan History API
When using the Scan History endpoint to list historical scans, you now can filter the results by Halo module (such as File Integrity Monitoring), server ID, server hostname, and scan status (such as failed). These new filters are in addition to the existing filters for date range and pagination.
This section lists selected customer-reported issues that were addressed for this release.
API intermittently returned empty password field for a new server account
Occasionally, user accounts created through the Halo API were returned with an empty password field. This issue has been addressed, and no further occurrences are expected.
Opening GhostPorts after logging into Portal through SSO
If your login to the Halo portal is through an SSO provider, you are now able to open GhostPorts without going through another authentication step, if you do so within one minute after logging into the Portal.
The following issues are among those that remain unresolved as of this release. Any known workarounds are described.
- 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