CloudPassage Halo — August 2013 Release
The August 2013 Release of CloudPassage® Halo® is a major release that adds support for SAML-based single sign-on to the Halo Portal. It also includes minor functional enhancements and fixes.
New Features in This Release
Portal Support for Single Sign-On
With this release, CloudPassage allows Halo customers to integrate their Halo Portal logins with industry-standard SAML-based single sign-on (SSO) solutions.
How SAML-based SSO works
SAML (Security Assertion Markup Language) is an open standard that supports a secure, XML-based solution for exchanging user security information between an identity provider (the organization that establishes the identity of a user, or principal) and a service provider (the provider of an application or service that the principal wishes to use).
Halo supports identity provider-initiated login, in which the user first logs into the identity provider's site and chooses the desired resource; the identity provider then sends an assertion to the service provider, who in turn makes the resource available to the user.
SAML-based SSO is available as a cloud service from several identity providers, including OneLogin, Okta, Ping Identity, and others. CloudPassage Halo can integrate with any single sign-on identity provider that is SAML v2.0-compliant.
Full instructions for configuring Halo for SSO and for providing required Halo information to an identity provider are given in Adding Single Sign-On to CloudPassage Halo.
Halo Integration With OneLogin
OneLogin (http://www.onelogin.com/) has developed an integration with Halo. On the OneLogin site, an application is available that an organization can configure to connect its users to the Halo Portal through SSO.
Features and Fixes in Previous Minor Releases
Since the last major release of CloudPassage Halo in May 2013, CloudPassage has released three minor production updates. The following documents describe the new features and improvements included in each update.
- New Halo Features and Fixes — 7 August 2013 Release
...includes expansion of several areas of the Cloudpassage API, plus minor changes in event generation and server-name display. Continue reading...
- New Halo Features and Fixes — 29 July 2013 Release
...marks the GA (General Availability) release of configuration security monitoring for Windows, adds enhancements to several areas of the CloudPassage API, improves the handling and display of file-integrity scans and baselines, and gives flexibility to the display of server names in the Portal. Continue reading...
- New Halo Features and Fixes — 15 July 2013 Release
...introduces strong two-factor authentication for Halo Portal login, gives more authentication flexibility to GhostPorts users, provides API access to scan history, introduces a revamped design for the Portal interface, and includes several minor functional enhancements. Continue reading...
The following are among the customer-reported issues that have been resolved for this release.
API: "List file integrity policies" call now returns all policies
Previously, deleting a baseline server would cause its file integrity policy to disappear from the results of the List file integrity policies call. The issue has been resolved; the list of file integrity policies now always includes all existing policies.
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