The January 2013 Release of CloudPassage® Halo® is a major release that includes the GA release of file-integrity monitoring, greatly enhanced from its beta version. The January release also includes new pre-built policy templates for both file-integrity monitoring and configuration-security monitoring, some intended specifically to aid with PCI DSS compliance. In addition, significant new functionality is available to programmers in the CloudPassage API.
With this release, the file-integrity monitoring feature of Halo moves from beta-level to General Availability. The G.A. version of file-integrity monitoring includes many greatly expanded or completely new capabilities, as described below. For full documentation of this new version, see Monitoring Server File Integrity With CloudPassage Halo.
Note: File-integrity monitoring is available only with the Halo Professional subscription package. If you currently are a Basic user and are interested in upgrading to Professional, you can use the self-upgrade feature in the Halo Portal, or you can contact CloudPassage Sales.
File-integrity monitoring now supports fully recursive scanning of directories, meaning that when you specify a directory as a target, you can also specify whether Halo is to scan only the top-level files in that directory, or whether it should scan all files and all subdirectories at all levels within the directory.
Whenever you specify that a directory is to be scanned, you can also specify one or more exclusions, or files/subdirectories within that directory that should not be scanned.
When you specify an exclusion, you can make use of the * or ? wildcards to create an expression that can specify the names of files or directories to exclude.
File-integrity monitoring now detects addition or deletion of directories as well as files.
File-integrity monitoring now scans the metadata of symbolic links as well as devices and special files such as named pipes. For a symlink, Halo does not detect changes to the content or metadata of the destination file that the link points to, but it does detect when the link has been changed to point to a different file.
Besides detecting content changes in files, file-integrity monitoring now detects changes in the metadata of files, directories, and symbolic links. The metadata collected includes user and group owners, file permissions, file ctime, and file mtime. Changes in ownership, permission, or file content are all are detected and reported as security events.
The default autoscanning state for file-integrity monitoring is now "enabled", meaning that scans will occur automatically at a default frequency. You can always change the frequency or disable automatic scanning entirely.
File-integrity monitoring now supports use of multiple baselines, meaning that one file-integrity policy can be associated with multiple server configurations. This flexibility allows you to define and use a server group in which, for example, not all servers are exactly 100% identical in versioning and patch level.
The Halo Portal interface has been extended to support multiple baselines. The file-integrity policy page displays a list of all baselines added to the policy, and the list of all file-integrity policies now includes a column for the policy's number of active baselines.
All baselines now have a user-defined expiration date (which can be "never").
Baselines can be added to an existing policy at any time, and baselines can now be deleted.
Whenever you run a baseline scan, Halo creates a baseline report that lists every target scanned on the baseline server, along with its metadata and cryptographic signature. You can use this report to validate your policy's target definitions and your baseline server's files and directory structure.
Policy functional enhancements
On the File Integrity Policy page, there is no longer an Enable checkbox for each target. All targets are enabled; to stop using one, you now need to delete it from the policy.
On the File Integrity Policies page (the list of policies), the Actions drop-down menu for each policy now includes a Deletecommand so that you can delete the policy.
You can now edit a file-integrity policy in either of two ways:
You can open the policy page and click the Edit button.
You can select Edit from the Actions drop-down menu for that policy in the list of policies on the File Integrity Policies page.
Limitation:Using the CloudPassage API to create a file-integrity policy with more than a thousand defined targets might result in (1) a timeout failure of the API method that creates the policy, (2) a failure of the baseline scan to complete, or (3) severe slowdown of the Portal UI when trying to display the policy.
For best performance, CloudPassage recommends that you use recursion (with exclusions as needed) to scan up to thousands of objects, while keeping the number of defined targets ( = lines in the policy) below a thousand.
Note: The "exceptions" feature replaces the "event suppression" feature available in earlier versions of file-integrity monitoring.
File-integrity monitoring now supports creation of exceptions, allowing you to temporarily suppress the display of individual results from file-integrity scans. You create exceptions on the Scan Results page or the Security Events History page by selecting events that you want suppressed and choosing the length of time that you want them to remain hidden.
It makes sense to define an event as an exception if you cannot or choose not to address it at the current time, although you expect to do so later.
The Halo Portal supports multiple selection when you create exceptions. You can select a number of events, then convert them to exceptions all at once.
All file-integrity exceptions are listed on the File Integrity Exceptions page, where you can view them, note their expiration dates, and remove them.
Important events related to exceptions are logged by Halo. The creation and deletion of any exception is captured and is displayable on the Security Events History page.
On the Scan Results page and on the Security Events History page, the display of a file-integrity event looks like this:
The metadata for the scanned target and for the baseline is shown in a drop-down. Links to the scanned server, policy used, and baseline server are available. Note the Add Exception button.
Scanning-settings events. Disabling and enabling autoscanning, making a change to the autoscan schedule, and making a manual scan request are captured as events and are available as search filters on the Security Events History page.
Policy events. The following policy-related actions are captured as events and are available as search filters on the Security Events History page:
File integrity policy created
File integrity policy modified
File integrity policy deleted
File integrity policy assigned
File integrity policy unassigned
File integrity policy imported
File integrity policy exported
Importing and exporting file-integrity policies
To provide support for policy sharing, the Halo Portal now includes an import/export facility for file-integrity policies. Exported policy files are stored as JSON-formatted text files that are both machine-readable and human-readable.
To export a file-integrity policy, go to the File Integrity Policies page and select Export from a policy's Actions drop-down menu. To import an exported policy file, go to the same page and click Import File Integrity Policy.
New CloudPassage API Features
With this release, the CloudPassage API is extended in the following areas:
File Integrity Policies API. Allows you to list all policies, get the details of a single policy, create a policy, update a policy, and delete a policy.
File Integrity Policy Baselines API. Allows you to list all baselines for a policy, list a single baseline, create a baseline (run a baseline scan), delete a baseline, and request a re-baseline (re-run a baseline scan).
Assign a file-integrity policy. (In the Server Groups API) Allows you to assign one or more file-integrity policies to a server group.
File-integrity events added to Events API. File-integrity events are now included in the set of security events that you can retrieve from the Halo database.
With this release, Halo includes new default policy templates for both configuration-security monitoring and file-integrity monitoring. You can use these new policies in your scans by cloning them, customizing them for your environment, and then assigning them to the server groups that you are scanning.
System-configuration monitoring policies:
Verify Use of Strong Crypto (Linux) v1 - Example. An example policy (you must customize it) that verifies that appropriate cryptographic protocols are active in your environment. Useful for addressing PCI DSS requirements 2.3 and 4.1.
Verify Retirement of Encryption keys (Linux) v1 - Example. An example policy (you must customize it) that helps you to verify that you have removed old encryption keys from your environment. Useful for addressing PCI DSS requirement 3.6.5.
Verify Time Server Settings (Linux) v1 - Example. An example policy (you must customize it) that verifies that your systems are set up to receive the correct time from industry-accepted sources. Useful for addressing PCI DSS requirements 10.4.1 and 10.4.3.
File-integrity monitoring policies:
Monitor Privilege Escalation (Linux) v1. Detects changes to files that are commonly modified by attackers to raise privileges or to maintain raised privileges.
Monitor Changes to Files with SETUID (Linux) v1. Detects changes to common files whose setuid permissions bit is set. These files are favorites for attackers to modify in order to gain elevated privileges.
Other Features and Fixes
Existing configuration policy templates consolidated, renamed, and and re-versioned
The Halo-provided OS-level configuration policy templates have been given more consistent (and usually shorter) names for this release, and their version numbers have been incremented from 2 to 3. However, the content of the templates has not been changed; the version 3 templates function identically to their version 2 counterparts.
Note also that separate Debian and Ubuntu templates have been consolidated into "Debian-based" templates that cover both distriibutions.
Previous template name
New template name
Amazon AMI, CentOS, Red Hat Enterprise, Fedora Linux Core Policy v2
OS Core (RPM-based Linux) v3
Ubuntu Linux Core Policy v 2.0.1
OS Core (Debian-based Linux) v3
Debian Linux - Core OS
OS Core (Debian-based Linux) v3
Amazon AMI, CentOS, Red Hat Enterprise, Fedora Linux Extended Policy v2
OS Extended (RPM-based Linux) v3
Ubuntu Linux Extended Policy v 2.0.1
OS Extended (Debian-based Linux) v3
Limited number of IP addresses allowed per IP zone
CloudPassage recommends that you include no more than 300 IP addresses and CIDR blocks in a single IP zone. If you need to specify a larger number, you can allocate them among multiple IP zones, and assign the zones individually to multiple, otherwise identical firewall rules.
Expired SVA exceptions removed from Portal display
When a software-vulnerability exception expires, it is now removed from the Exceptions page in the Portal. It remains in the Halo database, but it is no longer accessible to Halo users.
Updated alert emails regarding multiple events
Halo users who receive event alerts may see two different versions of alert emails. If the alert refers to 250 or fewer events, the total number of events is stated and the email lists the details of each event. If the alert refers to more than 250 events, the total number of events is stated but the email lists only the 250 most recent events.
New Features in Previous Minor Releases
Since the last major release of CloudPassage Halo in July 2012, CloudPassage has released five minor production updates. The following documents describe the new features and improvements added to each of the minor releases.
The following issues are among those resolved in this release.
Each viewing of a user's secret key now correctly generates a single log event, rather than two events, as occurred previously.
The following issues are among those that remain unresolved as of this release. Any known workarounds are described.
False-positive file integrity security events can occur in Linux systems in which the prelink utility 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 prelink on the baseline server before running the baseline scan. That should eliminate most or all false security events related to prelink.