This release introduces the new Traffic Discovery feature. When enabled, it appears under the Connections view in the Halo portal. Traffic Discovery provides visibility into traffic patterns exhibited by monitored hosts. Halo users can use it to visualize connection patterns between Halo-protected hosts and remote systems. Traffic Discovery gives you detailed information on both inbound and outbound connections that occur on any of your servers. That
information can in turn be leveraged to create firewall policies that allow acceptable traffic while blocking traffic that is unwanted or unnecessary to the functioning of the servers' systems and applications.

Traffic Discovery is available on a trial basis through the redesigned Halo UI. Ask your sales representative about enabling this feature on your account.

This release implements a new Policies screen, which is where you can view all policies, regardless of type. In this screen, you can also perform all of your policy management tasks. Alert Profiles can also be found on this page.

Note:  If you have not yet accessed the new UI and would like to try it out, go to https://support.cloudpassage.com/entries/98741577-Accessing-the-Redesigned-Halo for instructions. To view the Halo UI release notes from the new UI, choose Documentation Library from the Halo portal Main menu.

With this release, the workflow for viewing and manipulating policies has changed to support the role-based access control features of the new Halo UI. Previously, ownership of and ability to create Halo policies was confined to users in the root group of an account. Now, users at any level of the server group hierarchy can view, edit, and delete policies owned by their groups.

Note:   For the purpose of this discussion, "policy" means one of the documented Halo security policies, or an alert profile, or a firewall-related policy object (network interface, IP zone, or network service).

The new policies workflow functions like this:

• A policy has an owning group, specified in the REST API by the group_id field of the policy object. Halo users in a policy's owning group can view and edit the policy.

  Note:  Existing policies (created before this release) are by default owned by the root group.

• Users in a policy's owning group can transfer ownership of the policy to any one of the group's descendants.
• Users in a policy's owning group can also share the policy with descendant groups. Users in any of those descendants can then assign that shared policy to their group, but ownership remains with the original owning group.
• A user in any group can list and view all of the policies that are
  • Owned by the user's group or any of its descendants
  • Assigned to the user's group or any of its descendants
  • Shared by a parent or other ancestor group
• A user in any group can update and delete any of the policies that are owned by that group or its descendants.

You can now view all of the IP addresses assigned to an interface in a server's profile area in the redesigned portal.

With this release, it is now possible to delete a server group and apply its server tag to another new or existing server group. The action is supported in both the Halo portal and the Halo API.

Historical scan data for groups that no longer exist is retained by Halo, and with this release is available in the Halo portal (through the parent group that the deleted group used to belong to). It is also available through the Halo API.

Previously, the names of Windows server interfaces were displayed as long alphanumeric codes (GUIDs) in the Halo API and on the server information sidebar in the redesigned Halo portal. Now the API and the portal display the netmask for all IP addresses on the workload, the GUID, and the more readable Windows display name.

When a Windows user turns on file and printer sharing, Windows alters the local firewall to allow for it, but previous to this release Halo firewall updates overrode those rules.

To support sharing, the Windows firewall policy editor screen in the portal now includes the Allow File & Printer sharing firewall rules check box. When it is selected, Halo automatically creates the required firewall rules to support sharing.

Halo users and groups can be specified as connection sources or destinations in Firewall policy rules. Halo now ensures that any of those elements that is defined outside of the logged-in user's Halo group (and its descendants) will not appear in the selections lists used to specify sources and destinations.

Previously, Halo supported only a single IP address for each of a server's network interfaces. Therefore, a firewall rule that listed a server group as source or destination could not include all the IP addresses of the group's servers, if any of them had multiple IP addresses. The issue has been addressed, and firewall rules now can account for all addresses used.

Previously, in situations in which multiple installed packages on a server had the same package name (although not necessary the same version designation), vulnerability scans failed to report the presence of all such packages. The scan process has been improved to consider both package name and version designation in assessing vulnerability.

For a Halo user, a session timeout due to inactivity results in the user being logged out and taken to a Halo login page. Previously, timed-out users of the new Halo UI were presented with a login page for the classic Halo UI. That action has been corrected, and Halo uses of either UI are presented with the appropriate login page for them.

This release marks the availability of a new Halo agent for Windows and Linux platforms platforms. The version number is 3.7.5 for Linux and 3.7.0 for Windows. For more information, see the Halo Agent Release Notes.

The following administrative and policy RBAC fields have been added to CSM, FIM, LIDS, and Firewall policy objects, and to alert profile objects, network interface objects, IP zone objects, and network service objects:

• created_at. The date and time at which this policy was created.*
• updated_at. The date and time at which the policy was last updated. *
• created_by. The user name of the Halo user who created the policy. *
• updated_by. The user name of the Halo user who last updated the policy. *
• group_name. The Halo ID of the server group that owns the policy.
• grouping. The name zof the server group that owns the policy.
• shared. A boolean value. true if this policy is shared to the owning group's descendants; otherwise, false.
• used_by. An array of the group ID and group name of each server group that is using this policy.**

* Not returned for firewall-related objects.
** Not returned for firewall service or firewall interface objects.

On the Servers API endpoint, the interfaces array of the server object can include multiple entries for a single interface. This allows the array to specify more than one IP address for a given interface.

The completed_at field of the scan object, which holds a timestamp of scan completion, was removed from results returned by the Scan History endpoint. The field has now been restored.

Previously, attempting to return historical scan data could fail with an error for a server that has been deleted. The process has been corrected so that historical scan data for a server that no longer exists is returned without error.

Several new fields have been added to the alert_profile object on the Alert Profiles endpoint, to allow users to make the following changes programmatically:

• Modify the profile's name, description, or alert frequency
• Add or delete users
• Enable or disable alerting for critical or noncritical issues

If you create a policy (CSM, FIM, LIDS, or firewall policy, alert profile, network interface, IP zone, network service, or special events policy) using the Halo API v1, and if you do not supply a value for the shared field, Halo now returns a value of true for that field. What that means is that API-created policies will by default be shared with any descendant groups of the policy's owning group.

Known Issues

The following issues are among those that remain unresolved as of this release. Any known workarounds are described.

• New Halo UI uses browser time instead of user setting. In the legacy Halo UI, a user can select the time zone for which Halo is to display all date-time values. In the new UI, Halo instead displays times according the the user's browser time zone setting.
• 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.

• Assigned GhostPorts users may be invisible to a firewall policy's owner. When a user at a non-root level creates a firewall policy, an administrator at a higher level can add a GhostPorts user (also at a higher level) as a source or destination in a firewall rule of that policy. The policy's owner, however, cannot see the assigned user when viewing the rule in the portal—because the user is at a higher level than the owner.

  Workaround: Do not add a GhostPorts user to a descendant group's firewall policy rules if that user is out of the descendant group's scope.

• Cannot modify settings of a group that has out-of-scope policies. An administrator at a non-root level of the group tree cannot modify the settings of any accessible group with an assigned policy (or alert profile) that has become out of scope. This situation can arise if:
  • A policy owned by a higher level group is first shared and assigned to a descendant group, and then unshared by the higher-level group's site administrator. The policy remains assigned to the descendant group, but that group's site administrator cannot make any modification to the group settings.
  • A higher-level group's site administrator transfers the ownership of a descendant group's policy to a group that is out of scope of the descendant group. The policy remains assigned to the descendant group, but that group's site administrator cannot make any modification to the group settings.

  Workarounds: Do not transfer the ownership of a policy from one descendant group to another that is out of the first descendant's scope. Do not unshare a policy if it is assigned to any of your descendant groups.