CloudPassage Halo — 01 July 2014 Release
The 1 July 2014 Release of CloudPassage® Halo® includes a new Halo agent that can run in read-only mode, new functionality to find servers matching specific criteria (such as software package and version) via API, and saving that search for future use, and other enhancements and fixes.
New Features and Improvements
Agent can run as read-only
On both Linux and Windows platforms, the Halo agent can now be set to run as read-only. While running as read-only, the agent is not able to make any changes to the host on which it runs, but is otherwise a fully functional Halo agent; it cannot update its host's firewall, it cannot support Secure Server Access (GhostPorts), and it cannot create, delete, or make any changes to a server's local user accounts.
To switch an agent to read-only, you must specify "read-only" in the agent start command:
- On Windows, add
/read-only=trueto start the agent in read-only mode.
- On Linux, add
--read-only=trueto start the agent in read-only mode.
This setting persists through Halo agent restarts and upgrades. Therefore, to switch from read-only mode back to read/write mode, you need to explicitly reset it by restarting the agent, using
API now supports saving and retrieving searches
The Halo API now includes a Searches endpoint that allows you to list, create, read, update, or delete searches that are used to generate Halo reports. For example:
Each saved search is also easily executed by copying and running the provided HTTP Get request to the Halo API.
Additional criteria to filter "List servers" method
On the Servers endpoint of the Halo API, the "List servers" method
now supports the following new system-related criteria that you can use to filter the results returned:
- Server label (
- Connecting FQDN (
- Platform version (
- Operating system name (
- Operating system version (
- Chip architecture (
- Self verification result (
*For these search criteria, you can supply a substring of the full value (for example,
west.acme), and the search will
match any value of that field (for example,
c-127-63-31-15.west.acme.com) that contains the substring.
**Values for these search criteria need to be URL-encoded in the search URL (e.g., change "
These additions double the number of search criteria available for this call. See also the new vulnerability-related criteria (next).
Vulnerability-related search criteria for "List servers" method
On the Servers endpoint of the Halo API, the "List servers" method now supports the below vulnerability-related criteria that you can apply to filter the results returned. This means you can make an API call to get all servers with a certain package, CVE reference number, or KB present:
- Package name (
(note that this value must be URL-encoded (e.g., change "
Internet Explorer" to "
- Package version (
- Common Vulnerability and Exposure (
- Microsoft Knowledge Base ID (
- Missing Microsoft Knowledge Base ID (
(returns only Windows Servers without the specified patch; ignores Linux servers)
missing_kb, you can supply a substring of the full value (for example,
KB9772), and the search will match all values of that field (
KB97799) that contain the substring.
This section lists selected customer-reported issues that were addressed for this release.
"Network Service Accessibility" check with no port gives "indeterminate" scan result
Previously, it was possible to save a Network Service Accessibility configuration rule check that specified no port, and if that check was applied in any configuration scan, its resulting scan status would be "failed", incorrectly indicating that a policy violation had been detected.
Now, in such a situation, the scan status returned for the check is "indeterminate". Also, from now on the Halo portal does not allow a user to save a Network Service Accessibility check that does not specify a port.
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.