CloudPassage Halo — 31 March 2014
The 31 March 2014 Release of CloudPassage® Halo® brings automatic provisioning of Halo users to SAML-based single sign-on solutions with which Halo has integrated. The release also includes functional updates to firewall and configuration policies, UI improvements to the Halo Portal, and other minor enhancements and fixes.
New Features and Improvements
Automatic provisioning of Halo users for SSO
This release brings the convenience of automatic provisioning of Halo users to Halo's integration with SAML-based single sign-on (SSO) solutions.
In any integration of Halo into an SSO service, users of the service must exist in both the SSO provider's user base and in Halo's user base. Administrators can always add and update the users manually in both places, but with Halo's just-in-time autoprovisioning capability, users of the SSO provider are automatically re-created as Halo users whenever they first attempt to access Halo through the SSO service.
Halo uses information passed to it in the identity provider's SAML assertion to determine whether a user requesting access is already an existing Halo user. If the user is not, Halo creates the user's Halo account from information in the assertion. If the user already exists but some of the passed information is different from what is in the current Halo account, the Halo account is updated with the new information.
No Halo Portal interface is needed for enabling or managing this capability; it is always available within Halo. However, automatic provisioning of Halo users does require additional integration effort on the identity provider side, compared to manual user provisioning.
For more explanation of this capability as well as the Halo SSO integration feature as a whole, see Adding Single Sign-On to CloudPassage Halo.
Functional improvements to Configuration File Setting rule check
Clarified logic is now applied to the handling of comment characters and the NOT operator in the Configuration File Setting rule check. Changes:
- In parsing a line in a configuration file, Halo ignores any information following a comment character.
Therefore, in searching for a particular value for a given configuration item, and the item exists but it or its value follows a comment character, the result of the check is now FAIL (regardless of the value).
Likewise, in searching for "NOT a particular value" for a given configuration item, and the item exists but it or its value follows a comment character, the result of the check is now PASS (regardless of the value).
- In searching for "NOT a particular value" for a given configuration item in a given section of the file, if the file section is not found or if the configuration item is not found, the result of the check is now PASS.
New ability to add comments to Halo firewall policy rules
In both Linux and Windows firewall policies, it is now possible to create and save comments or descriptions for individual firewall rules. This ability is useful because, for example, security auditors may consider well documented firewall rules to be prerequisite for passing an audit.
Each comment can be up to 256 characters long, and may include letters, numbers, spaces, periods, and underscores.
When the Halo policies are converted to local iptables or Windows Firewalls on the servers, the descriptions are preserved and are visible. However, local updates to those comments are ignored by Halo and do not trigger "Server firewall modified" events or alerts.
New Portal UI for managing audit events
Besides logging events that may directly indicate serious security issues, Halo also logs a large variety of audit events, which mostly represent normal, everyday actions of Halo Portal users. Recording the history of audit events is useful for demonstrating compliance, and also useful in supporting correlation and forensic analysis in the wake of a security breach.
Previously, all supported Halo audit events have always been logged, have not been considered critical, and have not generated alerts. With this release, Halo site administrators have the flexibility to specify which events should be logged, which should be flagged as critical, and which should generate alerts.
To accomplish this, the site administrator accesses the new Audit Events tab on the Halo Portal's Site Administration page and sets checkboxes as appropriate.
Note: The list of events displayed on this tab does not include the server-related Halo special events (for example, "Server firewall modified" or "server restarted") or any security events generated by scans (for example, "Configuration rule matched" or "File integrity object signature changed"), because those events are configured elsewhere, in varous Halo policies.
Other Portal UI updates
- Templates menu. To provide better visibility for policy templates in the Halo Portal, a new top-level menu, Templates and Tools, appears in the Portal menu bar:
Menu items here give you direct access to templates for configuration policies, file integrity policies, and log-based intrusion detection policies.
- Idle session timeout. Previously, the timeout for Halo Portal sessions (the time after which an idle session logs out) was fixed at 30 minutes. Now, to address the needs of those who need to keep idle sessions open for much longer, as well as those who wish to cut off idle sessions more quickly, Halo allows for an idle time of as much as 24 hours or as little as 15 minutes.
If you are a site administrator, you can set the timeout for your account on the Authentication Settings tab of the Site Administration page in the Portal.
- New Daemon. This release marks the availability of version 3.0 of the Halo Daemon, on both Windows and Linux platforms.
- Daemon auto-deactivation. Halo re-classifies an active server as missing if its Daemon has unexpectedly not contacted the grid for an interval of 10 or more heartbeats. Previously, missing servers that did not re-contact the Grid remained in a missing state perpetually, unless manually deactivated through the Halo Portal.
Now you can enable automatic deactivation. If you are a site administrator, go to the Daemon Settings tab of the Site Administration page in the Portal to set the threshold for auto-deactivating your account's servers. Pick any setting from 15 minutes to 24 hours.
An important benefit of automatically deactivating missing servers is that it prevents the buildup of large numbers of missing, unused servers as sources or destinations in firewall policy rules.
CloudPassage API updates
- Get scan details. This is a new method added to the the Scan History endpoint. It returns the details of a scan specified by scan ID:
- Firewall rule comments. As noted above, you can now use the Halo Portal UI to add, view, and edit descriptive comments on your firewall policy rules. You can also do the same through the CloudPassage API, using the new
commentfield in the input and response JSON for the "Get firewall policy details including firewall rules" and "Create a new firewall policy" methods of the Firewall Policies endpoint.
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