CloudPassage Halo — 22 September 2014 Release
The 22 September 2014 Release of CloudPassage® Halo® features the beta release of the Halo reporting service, increases security for Halo logins by requiring browser authorization, adds new configuration policy rule checks, and includes other new features and improvements to both Halo and the Halo REST API.
New Features and Improvements
Reporting capability added to Halo portal
This release marks the initial availability of Halo reports, a new service of the Halo portal that allows you to perform detailed parametric searches of the Halo database to locate items or sets of items that you may wish to act on. This first release of the reporting service focuses on searching for individual servers or collections of servers that match any of a large number of criteria.
A new Reports menu appears in the top menu bar in the Halo portal. Click it to open the Reports page:
Use the search-criteria selectors on this page to set up a search query, and then click Submit to run it. The results of the most recent search are always displayed in the table below the criteria selectors.
You can search for servers using any combination of over 20 criteria. For some of the criteria, you can select a value from a dropdown list, and for others you can enter a text string.
You can save the results of a search in PDF or CSV format for export. A PDF report includes just the server fields displayed on the Reports page; a CSV report includes all fields of the server object, as defined in the Servers endpoint of the Halo REST API.
For more on the Halo reporting service, see Using Halo Reports in the Halo Operations Guide.
Browser authorization option for Halo portal access
To enhance the security of Halo portal access, Halo users are now required to register the individual web browser instances that they use to log into the Halo portal. The first time that a new Halo user attempts to log into the portal, the user is asked to authorize the browser being used.
If the user clicks Yes, the user is immediately logged in and the browser is authorized for 30 days, during which time the user is not challenged to provide an authorization code. If the user clicks No, the user is still logged in immediately, but the browser is not authorized for future logins.
After the first login, each time that the user logs in with a browser that is not already authorized, the user is required to register that browser by entering an authorization code that is sent to the user separately (by email).
- If the code is not accepted, the user cannot log in.
- If the code is accepted, the user is logged in immediately and the browser is authorized for 30 days.
- If the code is accepted but the user has cleared the Remember this device for 30 days checkbox, the user is still logged in but the browser is not authorized for future logins.
A Halo user can have any number of authorized browsers at any moment, but all authorizations last for 30 days only.
When is browser authorization required?
The browser authorization feature is required for all Halo users that use only user name and password for authentication. If your organization uses multi-factor authentication or single sign-on for accessing the Halo portal, you are not required to also enable browser authorization, and you can disable it on the Authentication Settings tab of the Site Administration page in the Halo portal. Nevertheless, for highest security CloudPassage recommends that you leave browser authorization enabled, regardless of which authentication method you use.
Rule check updates for Configuration Security Monitoring
New rule check: Password is not expired
This Linux check verifies that the specified local accounts all have valid (not expired) passwords. If any of the accounts has an expired password, the check fails.
New rule check: Directory presence
This check, available on both Linux and Windows platforms, verifies the presence (or absence) of a specified directory or set of directories on system. If you list multiple directories, they must all be present (or absent, if you select should not be present) or else the check fails.
New rule check: Mount point
This Linux check verifies whether a given file or directory is (or is not) mounted at a given point in the file system.
You can use this check to, for example, confirm that the log file
/var/log/messages is not mounted on the root partition (
/), where it could potentially fill up the system disk and cause an outage.
Halo REST API updates
Server searches by server_label are 'like' searches
When using the Halo API to search for servers with a given server label, the value you specify for the
server_label filter parameter need not be the full server label. The search returns all servers whose server label contains the exact substring you specify. For example:
would return servers with labels AcmeWest, acmewest, Acmewest-23, and webservers-acmewest.
Server searches sortable by several fields
You can specify that results for a server search are to be alphanumerically sorted (in either ascending or descending order) according to the values of any of the following server-object fields:
Server search by CVE now supports multiple CVEs
The Halo API has included the ability to search for servers with an installed package containing a given Common Vulnerability and Exposure (CVE). This release adds support for specifying multiple CVEs in the search command:
In the search, the specified CVEs are OR'd with each other; the results include all servers that contain any of the listed CVEs.
Other new features and improvements
New Halo agent available
Halo agent v. 3.2.10 for Windows corrects an issue with disabling DNS when installing Windows agents. Previously, using the startup command-line option /dns=false when installing a Windows agent did not disable DNS resolution, and furthermore prevented the agent from contacting the analytics engine to register itself. Executing a subsequent startup command would then disable DNS as expected, and would also allow the agent to contact the engine and register.
This release corrects both aspects of that issue. The startup command and options work as expected from the first start.
New special event: Multiple accounts detected with same UID
The global special events policy now includes the event type "Multiple accounts detected with same UID". The event is triggered whenever Halo detects more than one user account with the same UID on a server.
This event type is similar to the the existing event type "Multiple root accounts detected", but it applies to all UID values, not just zero.
Exceptions deprecated for File Integrity Monitoring
When you use use Halo File Integrity Monitoring, CloudPassage strongly recommends that you use it in its default configuration, in which all changes detected within a single directory target are grouped into a single event. This grouping can greatly reduce the total number of events returned for a scan.
In this configuration, File Integrity Monitoring does not support the use of file integrity exceptions. Exceptions are based on events, and therefore the occurrence of one change to a single file out of possibly hundreds in a target would, if made an exception, prevent changes in any of the other files from being reported in future scans.
If there are individual files or subdirectories within a target that you want File Integrity Monitoring to ignore, a preferable strategy is to add exclusions for those files to the target in your file integrity policy.
Disabling DNS host resolution on a server
If your organization's policies require that reverse DNS resolution of host names be disabled on your servers (for example, if resolution is performed instead on proxy machines), you can configure the Halo agent on each server machine to not perform the resolution for the heartbeat that calls that it makes to the Halo analytics engine.
The Halo agent now supports a start-up switch for enabling or disabling DNS resolution. By default DNS is enabled; to disable it, use the command-line option
--dns=false (on Linux) or
/dns=false (on Windows). The disabled state will persist through restarts.
If you need to re-enable DNS, use the analogous startup command option
Saving a report as CSV saves all fields, regardless of what the portal displays
The Reports page in the Halo portal allows you to execute a report and save the results in CSV or PDF format. If you save it as PDF, the saved report contains exactly the fields that the Halo portal displays. But if you save it as CSV, all defined fields in the report are saved, even those that may not appear in the UI.
If you execute a server search through the Halo API, the results are also available in JSON format. JSON and CSV results include all fields, whereas PDF results include only those fields that the UI would display.
Autocomplete for 'Server' field of Security Events History
On the Security Events History page, the drop-down list of available servers in the Servers field continually updates itself to include only server names containing the character sequence typed into the field. This capability allows you to quickly narrow down the list of servers to choose from.
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