Halo Operations Guide For Users of CloudPassage Halo

Transcription

Halo Operations Guide
For Users of CloudPassage Halo
Who should read this guide?
PART 1
BASIC HALO OPERATIONS
Using the Halo Portal
Log Into the Portal
Get Help
Change Your Password
Manage Your Account and Subscription
Invite and Manage Halo Users
Invite a New User
Edit an Existing User
Deactivate or Delete a User
Setting Up Servers and Server Groups
1. Install Daemons
Install Linux Daemons
Install Windows Daemons With the Installer
Install Windows Daemons from the Command Line
Install a Daemon on Your Gold Master Server
Deploy Daemons in Bulk With Automation Tools and Scripts
Add Custom Labels to Your Servers
Run your Halo Daemons in Read-Only Mode
Uninstall Halo Daemons
2. Organize Your Servers Into Groups
Design Your Groups
Create Your Groups
Maintain and Manage Your Groups
3. Assign Servers to Groups
Manually Assign Servers to Groups
Automatically Assign Servers to Groups
Maintain and Manage Your Servers
Activating Halo Features to Protect Your Servers
Choose the Halo Features to Activate
1
Assign Policies to Server Groups
Conduct Scans
Configure Automatic Scans
Manually Scan Selected Servers
Using the CloudPassage API
About the API
API Examples and Sample Code
PART 2
HALO ISSUES AND EVENTS
About Issues, Events, and Alerts
Defining Your Issues, Events, and Alerts
Flag Policy Issues for Logging and Alerting
Set Up a Special Events Policy
Set Up Alert Profiles
Addressing Issues
View a Server Group's Summary of Issues
Analyze a Server's Current Issues
View the History of an Issue
Act On Reported Issues
Addressing Events
View a Server Group's Summary of Events
Analyze a Server's Most Recent Events
Filter and View a Server or Group's Event History
Act On Reported Events
APPENDIXES
A Halo Site Administration
Users
API Keys
Authentication Settings
Scanner Settings
Daemon Settings
Advanced Settings
Set GhostPorts Session Length
List IP Addresses Authorized to Access Halo Portal
Choose Your Email Preferences
Enable Halo Beta Features
Audit Events
Master Account
B Multi-Factor Authentication
Enable Multi-Factor Authentication for a User
Log In With Multi-Factor Authentication
Verify Your Phone Number (for SMS Authentication)
2
Authenticate With an SMS Code
Authenticate With a YubiKey
Site Administrators: Set Up a Backup Authentication Method!
C Search Expression Syntax
Who should read this guide?
The Halo Operations Guide explains everything you need to know in order to access, configure, use, and administer
the CloudPassage Halo service—allowing you to provide strong, dynamic protection to all of your cloud and physical
servers all across the globe. From your first login to the Portal, through your first Daemon installations and your first
scans, all the way to your interpretation and remediation of a variety of security risks that your server fleet may face,
this guide steps you through the procedures and best practices that can guard your assets and intellectual property
against malicious actions.
Whether you are
A security specialist responsible for interpreting and acting on security issues and events
A DevOps architect responsible for designing Halo protection for your organization
A Security Ops admin responsible for implementing strong policies to secure your server infrastructure
A sysadmin responsible for conducting ongoing Halo operations across your networks
...this guide can help you to understand and take full advantage of the power of Halo in your work.
Note: This guide does not exist alone. It is the core document in a suite of guides that describe in detail each of
the specific security features and modules that Halo offers. The entire suite is available on the
CloudPassage Customer Support site, in the Documentation Forums.
PART 1
BASIC HALO OPERATIONS
CloudPassage Halo is a software-as-a-service offering that provides strong security for your cloud servers, across all
public, private, and hybrid could environments. In use, the components of Halo are distributed across the customer's
clouds and other clouds, as shown below.
3
The Halo Daemon is a lightweight and secure software component that runs as a service on each cloud server.
The Daemon monitors important server security factors, communicates with the Halo Grid as needed, and takes
actions based on pre-configured or customized security policies.
The Halo Grid is a powerful elastic compute grid that provides sophisticated analytics that evaluate data collected
by the Halo Daemons. The Halo Grid does the "heavy lifting" on behalf of the Daemons, preserving customer
server resources and performance.
The Halo Portal is the convenient "single pane of glass" used to manage all Halo product capabilities, create
policies, set up alerting, view reports, manage users, and other tasks.
The CloudPassage API gives you an alternative to the Halo Portal for managing Halo operations. Your
developers can create new tools or add Halo capability to existing tools.
Through the Halo Portal, you apply Halo's group-based policy management to efficiently add and manage security to
server fleets of all sizes. You can apply security policies at initial server launch, or at any time for operational servers.
Halo automatically monitors all servers and reports any security violations in real time. You can view recent and
historical violations in the Portal, and you can use the Portal to create, assign, and retire policies as needed.
All Halo users automatically have access to the Portal to create and manage server groups, control their Halo
accounts, apply any available Halo security features, conduct scans to detect security issues, respond to events and
alerts, and automate tasks through the CloudPassage API. Depending on your subscription and your account type,
you may also be able to install Halo Daemons, add and manage new Halo users, and activate additional Halo security
features.
Note: This document describes all Portal features, equivalent to what a Halo site administrator with a Halo
Professional subscription can access.
Topics:
Activating Halo Features to Protect Your Infrastructure
4
The Halo Portal is your view into your organization's Halo account and your control panel for managing it. the Portal
gives you access to all Halo features, activities, and information that you are authorized to view or manipulate.
Note also that only your account's information appears; you can see nothing of other Halo accounts, just as other
accounts' users can see nothing of yours.
Depending on your Halo subscription plan and the type of Halo user you are, you may be able to use the Portal to
Manage your password and account.
Invite others to become Halo users within your account.
Set Halo server groups, install Halo Daemons, and assign servers to groups.
Use Halo features to protect your servers' configurations, firewalls, file integrity, exploit resistance, or user access.
Manage the site settings for your Halo account—for example, configure security settings or manage API keys.
Create security policies that define issues to track, events to log, and alerts to send.
Review scan results for detected security issues and logged events.
Use this information to perform remediations or initiate incident response procedures, as indicated.
This section shows you how to perform the above tasks and more.
Note: If you are interested in a highly abbreviated tutorial to get you started with Halo, consider the
Halo QuickStart.
Log Into the Portal
You start using Halo by logging into the Halo Portal. Depending on your organization's policies, you will log in using
either password authentication or two-factor authentication.
1. Use your browser to log into the Halo Portal, at https://portal.cloudpassage.com. The Portal login page appears:
2. Enter your Halo username and password.
3. Click Submit.
5
For multi-factor authentication only:
After you enter your username and password, the Multi-Factor Authentication page for either SMS or YubiKey
appears. (If you are enabled for both types of authentication, the page allows you to choose which to use.)
Enter your SMS authentication code or insert your YubiKey. See Authenticate With an SMS Code or Authenticate
With a YubiKey for details.
If your password or multi-factor authentication is successful, the login is complete and the Halo Dashboard page
appears.
4. From the Dashboard, use the links and menus to access any of your available Halo features and information.
Besides logging into the Portal, you can also use the login page to reset your Halo password or even to register for
Halo if you aren't yet a user.
Note: Certain aspects and requirements for your organization's Halo login process are under the control and
responsibility of your Halo site administrator(s). If you are a site administrator, see Authentication Settings
for an explanation of the settings that you can modify. See also Advanced Settings if you need to control
the IP addresses from which Halo users are permitted to log in.
Get Help
Whenever you are logged into the Halo Portal, help with learning or using Halo is always just a few clicks away.
Select Support > Getting Started With Halo to view a short document that walks you through using Halo.
Select Support > File Support Request to contact CloudPassage Customer Support for help.
Select Support > Documentation and Forums to open the following dialog box:
6
To look up information about Halo, click Browse Documentation or Browse Support Forums to peruse the
documents in the Customer Support forums, including the Halo product documentation. See About the Support
Forums for more information.
To search for documentation on a specific topic, enter the topic into the field and click Search. Links to relevant
forum and documentation articles containing that term appear below the search box:
If instead you want to file a request for help with Customer Support, click File a Support Request . The New
Support Request form opens:
7
Fill in the fields of the form and click Submit. A support ticket for you is entered into the system. The support
team will contact you by email within 24 hours.
About the Support Forums
CloudPassage sponsors a number of user forums on the CloudPassage Support Community site. These forums are
open to the public and are a great source of information and ideas on how to learn and use CloudPassage Halo.
There are over 25 active forums, in the following categories:
Product Updates. Several forums, including "Release Notes" and "Customer Notifications".
Documentation. About a dozen forums, one for each available product guide.
Frequently Asked Question s. Several forums answering questions about Halo in general.
Feature FAQ. Forums answering specific questions about specific Halo features.
Tips and Tricks. Videos and insider insights from CloudPassage developers on how to harness the power of
Halo.
All documents in the forums are indexed for searching, making answers easy to find. You can also submit your own
questions, ideas, tips, and articles in the forums to help your fellow users or to receive help yourself.
Note: The Halo product team periodically runs beta programs on new features and content. If you'd like to
become one of our next beta testers, email us at beta@cloudpassage.com.
Change Your Password
When you need or wish to change your Halo password, you can do that from within the Halo Portal by selecting My
Account from the User menu (your name in the page header).
The Password Reset section of your account page lists your organization's password requirements (modifiable by a
site administrator; see Halo Site Administration ). It also includes fields for entering your current and requested new
password. Enter the information and click Save to submit the change request.
8
Note that you can also request a new password without being logged into the Portal. Click Reset your password on
the Portal login page and follow the instructions.
Manage Your Account and Subscription
To review or edit the details of your Halo account, select My Account from the User menu (your name in the Portal
page header). There you can view or change your username, first and last name, and time zone. And you can
choose to stop receiving daily status emails from CloudPassage, if you wish.
Note that you can't change your email address on this page. If you need to associate a different email address
with your account, contact a Halo site administrator within your organization. If you are a site administrator, you
can change your own email address and the email addresses of other users on another page; see Edit an Existing
User.
You can also reset your Halo password from this page, as described in Change Your Password .
If you are a Halo site administrator, you can also see and in some cases change the details of your Halo subscription
plan. Select Manage Subscription from the Site Administrator menu (the gears icon [
header).
] in the Portal page
Note: If you purchased Halo from CloudPassage with a purchase order or contract, you will not be able to
manage your subscription on this page. Instead, please contact Customer Support or your CloudPassage
account representative.
If the Manage Subscription page is available to you, you can use it to
9
Change the details of your billing plan (for example, the minimum number of servers you are billed for), update
your payment-card information, and view your invoices.
View your server-hour usage for the current billing period.
Upgrade or downgrade your Halo subscription plan (Halo Basic, Halo NetSec, Halo Pro).
Cancel your Halo subscription.
Halo standard users (non-site-administrators) do not have access to the Manage Subscription page.
Note: Your organization's Halo account may be registered directly with CloudPassage, or it may be registered
with a third party that manages your security services through a CloudPassage master account. If you are
a Halo site administrator, you have the ability to link your account to a master account or disconnect from
that master account. See Master Account for more information.
Invite and Manage Halo Users
If you are a Halo site administrator, one of your privileges is the ability to add other users to your Halo account. (Other
site-administrator responsibilities are described in Halo Site Administration.)
Having multiple users allows you to spread responsibility for separate Halo tasks (such as server-group administration
versus policy design versus security-event response) across multiple specialists in your organization.
Select Site Administration from the Site Administrator menu (the gears icon
in the Portal page header), then
select the Users tab. The User Administration table displays information about all current Halo users in your
organization. If there are many users, the list may break across several pages. You can sort the list by any of the
columns, and you can search for a value that appears in any column.
10
If you want to add a new Halo user to the account, click Invite New User (see next).
If you want to delete or deactivate a user, see Deactivate or Delete a User .
If you want to edit the information for an existing user, click Edit for that user. (See Edit an Existing User .)
Invite a New User
When you click Invite New User on the User Administration page, the following page appears. You "invite" a user
because the candidate receives an email invitation from Halo, and the user account is not active until the invitee
accepts by logging into the Portal.
1. To prepare the invitation, start by filling in the required personal information about the invited user.
Note that the username must be unique among all Halo users. A good way to ensure a unique name is to use
your email address as your username.
11
2. Decide whether to enable Portal access for the user. (A server administrator who will use Halo only for GhostPorts
multi-factor authentication to servers will not need Portal access.)
If the user is to have Portal access, decide whether it is to be as a standard user or as a site administrator. The
following table explains the differences.
Portal access
Site administrator
Standard user
GhostPorts-only
View the Halo Dashboard
✓
✓
View Security Events History, Scan History
✓
✓
Run scans
✓
✓
Install Daemons (can access Daemon Registration Key)
✓
Manage the Halo subscription
✓
Administer the Halo site (see Halo Site Administration )
✓
Manage "My Account"
✓
✓
Open GhostPorts
✓
✓
✓
Manage policies, exceptions, alert profiles
✓
✓
Access Halo Customer Support
✓
✓
3. Decide whether to enable multi-factor authentication for the user. There are two reasons for doing this:
The user will be using GhostPorts to log onto to one or more Halo-protected servers. See Using GhostPorts
Multi-Factor Authentication With CloudPassage Halo for details on why and how to use GhostPorts.
The user will be logging into the Halo Portal with two-factor authentication. See Two-factor authentication for
details on enabling it for your Halo users.
To enable two-factor authentication, first specify the user's authentication method. Select SMS code and Halo
Password, YubiKey and Halo Password , or both. The page expands to display additional fields.
4. Enter the required information into the fields. For detailed instructions, see Enable Two-Factor Authentication for a
User.
5. Select the GhostPorts checkbox if you want to enable GhostPorts access for the user, and have already enabled
multi-factor authentication.
6. Click Invite to commit your settings and close the Invite New User page. The user will receive the invitation by
email.
Edit an Existing User
When you click Edit for a Halo user listed on the User Administration page, the following page appears. Note that on
this page you can change only the following:
The user's email address
The user's multi-factor authentication enablement
The user's Portal access and user type
The user's GhostPorts enablement
12
See the descriptions of those fields in the previous section ( Invite a New User ) if you need more information.
Users can themselves change other information about their accounts on a different page; see Manage Your Account
and Subscription for details.
Deactivate or Delete a User
The Halo Portal gives you two ways to remove a Halo user from your organization's Halo account:
You can deactivate the user if he or she is no longer using Halo and is not expected to return to active status in
the near future. The user can no longer log into the Portal, but the user's name remains (marked "deactivated") on
the list of Halo users on the Site Administration page, the user's profile information is retained, and the user can
easily be re-activated by a Halo Site Administrator.
To deactivate a user, locate the user's name in the table on the Users tab of the Portal's Site Administration page,
then click Deactivate for that user in the Status column.
You can delete the user if it is certain that the user will never be re-activated, and if it is appropriate to destroy all
information about the user. A deleted user is not listed on the Site Administration page and cannot be reactivated; however, all historical information about the user is retained in the Halo database for audit purposes.
To delete a user, locate the user's name in the table on the Users tab of the Portal's Site Administration page,
then click Delete for that user in the Status column.
Readying your servers to be protected by CloudPassage Halo is a fairly simple three-step process:
1. Install a Halo Daemon on each server that is to be protected.
2. Create groups of structurally and functionally similar servers.
3. Assign each protected server to its appropriate server group.
You can perform the first two steps in either order: install Daemons first and then define groups, or define groups first
and then install Daemons.
13
Also, you can perform the steps manually through the Halo Portal, or in an automated fashion through integration with
third-party provisioning tools or by executing scripts that leverage the CloudPassage API.
1. Install Daemons
Every Halo-protected server must have a running Halo Daemon that performs security tasks and communicates with
the Halo Grid on a regular basis.
When you first log into the Halo Portal, you are prompted to install Daemons. When you are ready to do that, click
either Install Linux Daemons or Install Windows Daemons and follow the instructions on the page. Then repeat
the process for each of your servers.
If you need to find these pages again, navigate in the Halo Portal to Servers > Install Linux Daemons or
Servers > Install Windows Daemons .
You can install the Daemons manually, or you can automate the installation process .
Note: If you are a Halo site administrator, you have the ability to configure certain aspects of the behavior of
installed Daemons. See Daemon Settings for an explanation.
Install Linux Daemons
For every Linux server that you want Halo to protect, repeat the following steps:
1. Install a version of the sudo package on the server.
2. SSH into the server.
3. From your browser, log into Halo and follow instructions to download the correct script for your Linux distribution.
Or SSH into the server and download the script directly to the server.
4. On the server, execute the entire script at once, or perform each of its commands interactively, as shown on the
instructions page. The script supplies your unique Daemon registration key to Halo.
That's it! Your Linux server now appears in the Halo Portal Dashboard, in the All Servers group.
Performing an upgrade installation on Linux:
On any of the supported Linux platforms, you perform an upgrade installation by executing the appropriate upgrade
script for the platform. Download the script from the Install Linux Daemons page in the Halo Portal.
If you perform an upgrade while the older Daemon is running, the new Daemon will start automatically when the
14
upgrade is complete. If you stop the older Daemon and then upgrade, the new Daemon will not start automatically.
Configuring Linux Daemons for a proxy:
If your Linux server is configured to use a proxy, you'll need to supply the proxy information to Halo so that the
server's Daemon will be able to communicate with the Halo Grid. You can do that by adding the following options to
the command line when you first start the Halo Daemon (the same time that you supply the Daemon registration key):
--proxy=ip:port --proxy-user= username --proxy-password= userpassword
On subsequent starts, it is not necessary to include the proxy-related options (or the Daemon registration key) on the
command line. Note that if you later remove proxy support from the server, you should restart the Daemon and use
the --noproxy option. Or, if the proxy information changes, you can restart and include the updated values for the
proxy-related options.
Install Windows Daemons With the Installer
For every Windows server that you want Halo to protect, repeat the following steps:
1. Remotely log into your Windows server and start Internet Explorer as administrator.
2. From IE on the server, Log into the CloudPassage Halo Portal.
3. Navigate to Servers > Install Windows Daemons and download the Halo Daemon installer.
4. Run the installer and enter your Daemon registration key.
That's it! Your Windows server now appears in the Halo Portal Dashboard, in the All Servers group.
Performing an upgrade installation on Windows:
If you are upgrading from a 64-bit Halo Daemon (version 2.7.8 or later), you need not perform any explicit upgrade
procedure. The Windows installer senses that there is an existing Daemon and takes the appropriate upgrade
steps.
If you are upgrading from a 32-bit Halo Daemon (version 2.5.6 or earlier), take these steps:
a. Connect to your server through RDP and open Add/Remove Programs.
b. Remove the Daemon from your server by following the steps in Uninstall Halo Daemons.
c. In the Halo Portal, note the server group that the (now deactivated) server belongs to. Then move the server
into the "Retired" group, or simply delete it from Halo if you do not want to preserve a record of its configuration
or history.
d. Proceed to install the new server as described above.
15
e. Back in the Halo Portal, select your server from the "Unassigned" group and add it back into its appropriate
server group.
Note that Halo considers this as a new installation rather than an upgrade, since the configuration of your 32-bit
server and its server-group assignment are not carried over to your 64-bit server.
Configuring Windows Daemons for a proxy:
If your Windows server is configured to use a proxy, you'll need to supply the proxy information to Halo so that the
server's Daemon will be able to communicate with the Halo Grid. You can do that in the Windows Daemon installer,
on the Enter Proxy Information screen:
If you later remove proxy support from the server, you can use the Windows Service Manager to stop and restart the
service, specifying /noproxy in the Service Manager's "switches to pass to the service" field. Or, if the proxy
information changes, you can restart and include the updated values for the /proxy, /proxy-user, and /proxypassword options in the "switches..." field.
Install Windows Daemons From the Command Line
You can use the CloudPassage installer in a non-interactive mode to install a Halo Daemon without user intervention.
This capability allows you schedule installs, perform remote installs without a remote administrator, and use a single
command to bulk-provision an entire server installation with Halo Daemons.
Note: The non-interactive installer works for upgrade installs as well as for new installs. See Performing an
upgrade installation on Windows , above, for information on upgrading from different Daemon versions.
1. Run a command-prompt window as administrator: right-click the command-prompt icon (for example, in the Start
menu) and select Run as administrator from the context menu.
2. Change the current directory to the folder that contains the Halo installer file.
3. Execute a command with the following syntax:
cphalo-x.y.z-win64.exe /S /DAEMON-KEY= RegKey [/D=installdir] [/TAG=servertag]
[/NOSTART]
where
x.y.z
= The version number of the Windows Daemon that you are installing. The version number is
part of the filename of the downloaded installer executable.
S
= Specifies that the installation should be silent (unattended). Must be uppercase.
RegKey
= Your 32-character Halo Daemon registration key.
installdir = (optional) The directory into which to install the Daemon. If you specify nothing, the Daemon is
16
installed in the Program Files folder. (Enclose the path in quotes if it contains spaces.)
servertag = (optional) This Daemon's server tag. See Automatically Assign Servers to Groups .
NOSTART
= (optional) Specifies that the Daemon should not start up after installation. By default, the
Daemon starts when installation completes.
After you have constructed this command line, you can execute it directly or you can enclose it in a batch file for later
execution.
Install a Daemon on Your Gold Master Server
If you use "gold master" versions of your servers as templates from which to create cloud instances, you may want to
install Halo Daemons on the gold masters. Then, when you create server instances, each will already have an
installed daemon.
The installation process is the same as for installing on a cloud server. And CloudPassage recommends that you
start the Halo Daemon service after installing, by leaving the Start CloudPassage Halo Daemon now checkbox
selected. Doing that will ensure that any cloud instances created from the gold master will have unique Halo IDs and
will receive all updated Halo policies.
Deploy Daemons in Bulk With Automation Tools and Scripts
You can integrate Halo with cloud management and IT automation tools—such as RightScale, Puppet Labs Puppet,
and OpsCode Chef—to transparently embed Halo security into an automated server provisioning process. For
example:
Puppet is a well-known tool that you can use to provision Halo across multiple servers. CloudPassage has made
an example Puppet module available to customers. It uses a standalone Puppet deployment in which both the
master and agent are running on the same server. You may wish to use our Puppet example as a starting point
for developing your own automated Halo provisioning method. See this Blog post for more details.
CloudPassage has also prepared a pair of Chef cookbooks—one for Linux servers and one for Windows servers—
containing recipes for installing Halo Demons on your servers. You would add the appropriate cookbook to your
Chef run list, and then execute the run list on a set of servers. See this Blog post for more details.
CloudPassage has also created integration scripts with RightScale to automate the installation of Halo Daemons in
a RightScale-managed environment. The RightScript works with any type of RightScale account, and can be run
as either a boot script or an operational script. See this forum post on the CloudPassage Support site for more
details.
Add Custom Labels to Your Servers
An optional label attribute has been added to Halo servers. The attribute is called label in the Halo portal, and
server_label in the Halo API. It is an alternative to the existing hostname and FQDN attributes assigned to each
server. If a non-null value exists for a server's label attribute, the label is displayed everywhere in the portal UI, in
place of the hostname or FQDN.
The label attribute has been implemented to allow you to use Halo to assign more user-friendly or explanatory names
to your servers.
Note: A server label can be up to 80 characters long and can contain only alphanumeric characters plus dots,
dashes, and underscores. No spaces or other characters are allowed.
You cannot specify a server label from within the Halo portal or through the Halo API; instead, you add a parameter to
the Halo agent's startup command, as follows:
(Linux) Modify the agent startup script:
17
Use the --server-label option on the start command line, as in
sudo /etc/init.d/cphalod start --daemon-key= yourDaemonKey --server-label=yourServerLabel
(Windows) Execute an unattended installation:
Use the /server-label yourServerLabel option on the command line.
(Windows) Use the Windows Service Manager after installation:
a. Open the Services control panel. For example, from the Start menu, select Administrative Tools and then
Services.
b. Right-click the line for the CloudPassage Halo Daemon service, then select Properties from the drop-down
menu.
c. In the Properties dialog, enter the label assignment in the Start parameters field, using this format:
/server-label=yourServerLabel
d. Now start the service by clicking Start.
Important: Do not click OK without first clicking Start. If you click OK first, the tag will not be assigned to
the agent.
Run Your Halo Daemons in Read-Only Mode
On both Linux and Windows platforms, the Halo Daemon can be set to run in read-only mode. In that mode, the
Daemon is not able to make any changes to the host on which it runs, but it is otherwise a fully functional Halo
Daemon. In enterprise environments in which the security team does not have the authority to employ tools that have
privileged access to the organization's servers, running Halo in read-only mode is a viable alternative that retains
most Halo capabilities.
While running in read-only mode, an agent cannot update its host's firewall, it cannot support GhostPorts Multi-Factor
Authentication, and it cannot create, delete, or make any changes to a server's local user accounts.
You specify the running mode at agent startup:
On Windows, add a mode flag with a value of either read or read/write to the start command. (Default =
18
read/write.)
On Linux, add add a --readonly option with a value of either true or false to the start command. (Default =
false.)
The mode setting persists through Daemon restarts and upgrades. Therefore, to switch from read-only mode back to
read/write mode, you need to explicitly reset it, as in mode=read/write or --readonly=false.
Uninstall Halo Daemons
If you no longer want Halo to protect a server, you can uninstall its Halo Daemon. Once you do that, the server does
not appear on the Dashboard or other pages in the Halo Portal, and you can no longer access it or manipulate it from
the Portal.
Note: Uninstallation instructions appear on the Daemon installation pages of the Halo Portal.
Uninstalling on Linux
For Debian or Ubuntu, run this command on a server to remove its Daemon:
sudo apt-get purge cphalo
For CentOS, Fedora, RHEL, and Amazon Linux AMI, run this command on a server to remove its Daemon:
sudo yum remove cphalo
Uninstalling on Windows
Through the Windows user interface:
You can uninstall the Halo Daemon using Add/Remove Programs.
1. From the Start menu, select Administrative Tools > Services .
2. In the Services control panel, locate the Halo Daemon service, and stop it if it is running.
3. Open the Add/Remove Programs control panel.
4. Select the Halo Daemon service from the list, and click Uninstall.
The Halo installer launches, displaying the Uninstall page:
5. Click Uninstall. The Halo Daemon is removed from your server.
19
From the command line:
You may be able to use the following command to silently uninstall the Halo Daemon from a server:
installDir\Uninstall.exe /S
where installDir is the Daemon's installation directory (by default C:\Program Files\CloudPassage or
C:\Program Files (x86)\CloudPassage ).
Note: If User Account Control is enabled on a server, it may not be possible to execute this script unattended on
that server.
2. Organize Your Servers Into Groups
The concept of server groups is fundamental to Halo. Halo uses group-based policy management, meaning that an
individual security policy is designed to apply to any number of individual servers of a given kind. There is no need to
create an individual policy for each individual server. By applying policies in this manner, you can efficiently scale your
protection to fleets of thousands of servers. And in the dynamic environment of the cloud, Halo can instantly apply the
proper group policy to any newly cloned or burst server.
Design Your Groups
A server group is a set of similar servers—such as all of the web servers, or all of the load-balancers—that can share
a single Halo security policy. For example, all servers in a given group will use the same firewall policy and the same
configuration policy. In the Halo Portal, you will assign a policy to a server group, not to an individual server. So you'll
need to create server groups before any of your Halo policies can take effect.
To come up with the best set of groups for your organization, examine all of the servers you currently use, and
categorize them in terms of platform, applications, and purpose, while trying to end up with the smallest possible
number of groups.
The basic idea is that all the servers in a group need to be very similar (same O.S. and version, same applications,
same firewall needs, same local user accounts) because a single set of policies covers all of them. However, it is not
always strictly true:
You can mix Linux and Windows servers in the same server group for those features (such as dynamic firewalls,
configuration security monitoring, and file integrity monitoring) that allow assigning both a Windows and a Linux
policy to a group.
20
You can do this because Halo automatically applies only Windows policies to Windows servers, and only Linux
policies to Linux servers.
Servers (of a given platform) within a group must have identical firewall needs if you are implementing Halo
firewalls.
Servers (of a given platform) within a group must have identical or very similar system-file and directory structures
if you are implementing system configuration scanning or file integrity monitoring at the system level.
Servers (of a given platform) within a group must have the same general application security needs if you are
extending configuration security monitoring or file integrity monitoring to the application level.
You probably will not want to mix strongly dissimilar distributions of the Linux platform (Ubuntu with CentOS, for
example) within a server group, as this will make it harder to define configuration-policy rules that apply across all
servers.
You can share a single policy among several groups when that makes sense. For example, a web-server group
might need a different firewall policy from a database-server group, but if the two groups' operating systems are
identical, they might be able to share the same system-level configuration policy.
Create Your Groups
Once you have designed your groups, create them in the Halo Portal. On the Dashboard page, click the Add a New
Group link at the bottom of the list of server groups.
For now, just give each group a name and optionally a description; you'll assign servers and policies to the groups
later. The group now appears in the list of server groups on the Dashboard.
About Halo built-in server groups
Halo includes several built-in groups that you can use in special situations.
All Servers. This meta-group consists of all servers that have an installed Halo Daemon, regardless of whether
they are assigned to an actual server group. As soon as you install a Daemon on a server, it appears in this server
group, from which you can assign it to the server group of your choice. (Retired servers are not listed under this
group.)
21
Unassigned. This group consists of all servers that have not been assigned to a server group (although they do
appear in the "All Servers" meta-group). As soon as you install a Daemon on a server, it appears in this server
group, from which you can move it to the server group of your choice.
Retired. This group consists of all servers that explicitly have been retired (see Maintain and Manage Your
Servers). Move servers to this group when they are no longer used and you expect never to use them again.
Unretired. This group consists of servers that were retired, but are now deemed useful again. Note that when a
server is retired, it loses its server-group membership; therefore, unretiring it puts it into the "Unretired" group, not
into its previous server group. However, you can assign servers from this group to any actual server group for reuse.
Maintain and Manage Your Groups
Use the Halo Portal on an ongoing basis to manage your server groups. You can edit a group's name, add or remove
any of its servers, and add or remove security policies as noted in Assign Policies to Server Groups .
When you no longer need a given server group, you can delete it. Select the server group on the Halo Dashboard,
and click Delete below the group's name. If the group contains servers, Halo moves those servers to the
"Unassigned" group and then permanently deletes the group.
3. Assign Servers to Groups
If you have both created Halo groups and installed Halo daemons on your servers, you can now assign the servers to
the groups. A server must be a member of a group to receive the Halo security policies that protect it.
Manually Assign Servers to Groups
1. On the Halo Portal Dashboard page, Locate the servers on which you have installed Daemons. They should be
listed in the "Unassigned" group, and also in the "All Servers" meta-group. ("Unassigned" includes only servers
that have Daemons but belong to no server group. "All Servers" includes every server in your installation that has
an installed Daemon, whether or not it belongs to a group.)
2. For each server group that you have created, select the checkboxes for all of the servers that you want to assign
to that group, then select Move Server(s) from the Actions drop-down list, and then select from the group list the
22
name of the group to move those servers into.
Your selected servers are now assigned to their server group. As you create policies (see following sections), you can
return to the Dashboard page to assign them to the appropriate groups.
Automatically Assign Servers to Groups
Halo also allows you to automate the process of assigning servers to groups, bypassing manual assignment in the
Portal. To set it up, do this:
1. When you create or edit a server group in the Halo Portal, specify a server tag for that group. The server tag is a
string of your choice. Enter the string into the Server Tag field on the Edit Group Details page for that group.
Note: A server tag can be up to 40 characters long and can contain only alphanumeric characters plus dots,
dashes, and underscores. No spaces or other characters are allowed.
2. Then, when you install a Halo Daemon on a server, supply the server tag of the group to be associated with that
daemon. If a daemon's server tag matches that of any existing server group, that server is automatically assigned
to the group whenever the Daemon starts up.
There are several ways to assign a server tag to a Daemon:
(Linux) Modify the server startup script:
Use the --tag option on the start command line, as in
sudo /etc/init.d/cphalod start --daemon-key= your-daemon-key --tag= servertag
(Windows) Run the installer:
The installer includes a screen that you can enter the tag into.
(Windows) Execute an unattended installation:
Use the /TAG servertag option on the command line.
23
(Windows) Use the Windows Service Manager after installation:
a. Open the Services control panel. For example, from the Start menu, select Administrative Tools and then
Services.
b. Right-click the line for the CloudPassage Halo Daemon service, then select Properties from the drop-down
menu.
c. In the Properties dialog, enter the tag assignment in the Start parameters field, using this format:
/tag=tagName
d. Now start the service by clicking Start.
Important: Do not click OK without first clicking Start. If you click OK first, the tag will not be assigned
to the Daemon.
Note: It is also possible to add servers to groups programmatically. See the Servers section of the
CloudPassage API Developer Guide for details.
Maintain and Manage Your Servers
Use the Halo Portal on an ongoing basis to manage any of your servers. On the Dashboard page, activate a Halo
), then select a server group (or "All Servers"). Then scroll or search to find the
module by clicking its icon (such as
server(s) of interest, selecting the checkbox for each server you want to act on.
Searching for a server
To use the Dashboard search to find a server, enter any portion of the server's hostname, fully qualified domain name
(FQDN), or server label into the search box, then click Search. The search results are limited to the currently active
Halo module and the currently selected server group.
From the search results, select the checkboxes of the servers you want to act on.
Acting on a selection of servers
24
Once you have selected one or more servers to act on, use the Actions drop-down menu to
Launch scans of the servers.
Move the servers servers from one server group to another, including "Unassigned" if you do not want the servers
to belong to any group.
Retire the servers if they are not currently needed, putting them into the "Retired" group.
Unretire the servers from the "Retired" group, transferring them to the "Unassigned" server group (and "All
Servers" as well).
Delete the servers when you no longer need them and are sure that you never will again. The servers disappear
from the server group on the Dashboard and cannot be recovered.
Note: The Delete action removes the server's record from Halo, but it does not uninstall the Halo Daemon
from the server, and the Linux or Windows server still exists as a virtual or physical server, even
though it is no longer visible to Halo. To actually remove the Daemon from the server, follow the
instructions in Uninstall Halo Daemons.
Activating Halo Features to Protect Your Infrastructure
The capabilities of Halo to protect your server infrastructure can be grouped within the general areas of
Server integrity and intrusion detection
Firewall and access control
Security event logging and alerting
Within each of these security categories, you can enable the specific Halo features necessary to achieve both broad
and deep protection for your server fleet.
Whether your goal is to meet organizational or regulatory compliance objectives, to protect valuable intellectual
property, or to guard against destructive attacks on your organizational infrastructure, deploying the appropriate set of
Halo features can significantly strengthen the security posture of your systems and applications, regardless of
architecture.
Choose the Halo Features to Activate
Depending on your Halo subscription plan, you may have access to only a subset of these security features, or you
may be able to implement them all. Implementation is in general fast and simple.
25
Threat Management:
Configuration security monitoring . Automatically monitor operating system and application configurations,
processes, network services, privileges, and more.
Available on Windows and Linux platforms. Requires a Halo Professional subscription. Implement it by creating
configuration policies or cloning them from templates, and then assigning them to server groups. See Monitoring
Server Configuration Security With CloudPassage Halo for details.
File integrity monitoring . Use cryptographic signatures to detect unexpected changes to system binaries,
configuration files, source code, and other critical files (including registry keys on Windows servers).
Available on Windows and Linux platforms. Requires a Halo Professional subscription. Implement it by creating or
cloning file integrity policies, running baseline scans, and assigning the baselines and policies to server groups.
See Monitoring Server File Integrity With CloudPassage Halo for details.
Software vulnerability assessment . Scan the packages installed on your server for security vulnerabilities
(NIST CVEs).
Available on Linux platforms. Requires a Halo Professional subscription. Implementing it requires no action; it is
always enabled. See Assessing Software Vulnerabilities With CloudPassage Halo for details.
Access Control:
Firewall automation . Centrally manage host-based firewalls including automatic updates for when servers are
added, changed or retired.
Available on Windows and Linux platforms. Available to all Halo users. Implement it by creating firewall policies
and assigning them to server groups. See Automating Server Firewalls With CloudPassage Halo for details.
GhostPorts multi-factor authentication . Use strong authentication to dynamically provision and de-
provision network access for authorized users.
Available on Windows and Linux platform. Requires a Halo NetSec or Professional subscription. Implement it by
enabling specific users and modifying certain firewall policies. See Using GhostPorts Two-Factor Authentication
With CloudPassage Halo for details.
Server account management . Evaluate who has accounts on which cloud servers, what privileges they
operate under, and how accounts are being used.
Available on Linux platforms. Requires a Halo NetSec or Professional subscription. See Managing Server
Accounts With CloudPassage Halo for details.
Threat Detection:
Log-Based Intrusion Detection . Monitor system and application log files across your servers, generate
alerts whenever events that could indicate compromise or attack are logged.
Available on Windows and Linux platforms. Requires a Halo Professional subscription. Implement it by creating or
customizing a log-based intrusion detection policy that specifies which log files to inspect and what event text or ID
to alert on. See Using Log-Based Intrusion Detection with CloudPassage Halo for details.
Event logging and alerting . Securely store and generate real-time alerts for server creation, changes,
exposures, policy violations, and more.
Available on Windows and Linux platforms. Available to all Halo users. Implement it by flagging policy rules for
logging and alerting, and by creating special events policies. See Defining Your Issues, Events, and Alerts in this
document for details.
Consult the above-mentioned documents for the complete instructions you need to implement and manage these
Halo features. Then continue with this Operations Guide for
Instructions for assigning feature-specific policies to server groups and running scans of your servers.
26
Information needed by site administrators for ongoing Halo configuration and administration.
Instructions for all Halo users on how to set up and interpret security issues, events, and alerts across all Halo
features.
Assign Policies to Server Groups
Once you have implemented one or more Halo features, you can then complete the setup of any of your server
groups. The final step is to assign a Halo security policy to the group. In particular, you cannot use firewall
automation, configuration security monitoring, or file integrity monitoring until you assign the appropriate policy to the
appropriate group or groups.
Do that from the Halo Portal Dashboard by first choosing to edit a particular server group:
Then make the policy assignment on the group's Edit Details page:
These instructions may also be found in the individual feature documents listed in the previous section.
Note also that other server-group settings you can enter on this page include Special Events Policy and Alert
Profiles (described later, under Set Up a Special Events Policy and Set Up Alert Profiles ), and Server Tag
(described earlier, under Automatically Assign Servers to Groups ).
Conduct Scans
Once you have set up and configured one or more Halo features, use the Halo Portal on an ongoing basis to scan
your servers and interpret the results.
For configuration security monitoring, file integrity monitoring software vulnerability assessment, and server account
management, you can conduct scans of your servers either manually or automatically.
27
Configure Automatic Scans
If you are a Halo site administrator, you can enable, disable, and schedule automatic scans of your servers. Select
Site Administration from the Site Administrator menu (the gears icon
the Scanner Settings tab.
in the Portal page header), then click
For each Halo feature, select the checkbox to enable automatic scanning, and choose a scan frequency (from hourly
to weekly). Select Execute scan on daemon start if you want each server to be initially scanned as soon as its
Daemon starts up, instead of at a default time of day. (This is recommended, to avoid having all servers on your
network being scanned at the same time.)
To turn autoscanning off, clear the Enable Automatic Scanning checkbox.
You can modify certain other scan settings on this page:
Mark finding as Failed if the check was indeterminate . See About Indeterminate Results in Monitoring Server
Configuration Security for an explanation of when you might want to enable this setting for configuration scans.
Mark finding as Critical if CVSS score is above . Default threshold value = 5.00. See Adjust the Vulnerability
Threshold in Assessing Software Vulnerabilities for an explanation of when you might want to alter this value in
software vulnerability scans.
Generate a separate event for every change detected by a file integrity monitoring rule . Select or clear the
checkbox, depending on whether you want to group all the changes detected for a given policy target into a single
event or issue. See Specifying File integrity Monitoring Settings (in Monitoring Server File integrity with
CloudPassage Halo) for further explanation.
Manually Scan Selected Servers
28
At any time, you can manually kick off a scan of a single server, a selected set of servers, or all servers in a given
server group. You might want to run a manual scan if, for example, you have just remediated a reported issue or
vulnerability and you don't want to wait for the next scheduled scan to verify that the issue is no longer reported in the
scan results.
On the Portal Dashboard, select any server group (including "All Servers", if desired) and scroll or search for servers
of interest. Use the checkboxes to select a single server, multiple servers, or all servers in the group. Then select
Launch Scan from the Actions menu. Your scan starts immediately.
After a manual or automatic scan completes, you can interpret the resulting security issues and events. See Part 2 of
this document, Halo Issues and Events , for suggestions on how to proceed. See also the individual guides listed
above, under Choose the Halo Features to Activate , for instructions specific to each feature.
The CloudPassage application programming interface (API) offers a secure, authenticated way for programs to
directly access Halo functionality. Your client software can automatically perform many of the same functions that
Halo Portal users perform manually, such as creating and managing policies, creating or deleting server groups, and
running scans.
All Halo users have access to the API.
About the API
The CloudPassage API is a representational state transfer (REST) API. Its calls accept and return stored Halo
resources. You access those resources through URL paths. To make an API call, your application submits an HTTP
request and parses the response. The request and response are both in Javascript Object Notation (JSON) format.
Authentication and API Keys
All access to the CloudPassage API requires authentication. First, your application or script client must authenticate
with Halo to request an access token for the session. Your client then submits that token with every API call that it
makes. (Note that the token is valid for only 15 minutes, so if your session lasts longer than that, you'll need to obtain
another token.)
Your client must provide client credentials in the form of an API key when making the token request. One
responsibility of a Halo site administrator is to generate API keys for use by Halo client programs that access the API.
Your API keys are available in the Halo Portal, on the API Keys tab of the Site Administration page. See API Keys for
instructions on generating API keys and using them in your programs.
API Coverage
The API allows you to automate many aspects of Halo functionality. These are the API endpoints, the Halo resources
that you can manipulate in various ways through calls to the API:
Users [Halo users]
Server Commands
Server Groups
Server Scans
Servers
Scan History
29
Server Accounts
Configuration Policies
File Integrity Policies
Firewall Interfaces
Special Events Policies
File Integrity Baselines
Firewall Services
Events
Firewall Policies
Firewall Zones
Alert Profiles
Firewall Rules
Log-Based Intrusion Detection Policies
Saved Searches
Documentation
The CloudPassage API is fully documented in the CloudPassage API Developer Guide . Related blog posts are also
available, on the Cloud Security Blog .
API Examples, Sample Code, and the Halo Toolbox
CloudPassage customers have used the API to construct their own server-security management tools and to
integrate Halo with other systems. CloudPassage employees have also created code samples, scripts and libraries
that use the API to accomplish various useful tasks.
The Halo Toolbox is a set of GitHub repositories where CloudPassage customers and employees can share and
compare code that automates tasks by calling the CloudPassage API. The Toolbox facilitates collaboration:
You are encouraged to fork any of the repo's in the toolbox that interest you, then extend or improve them.
If you would like to share your extension or improvement, just send a pull request.
Click Watch for any repo to be alerted of changes to it.
The following are a few examples of the kinds of automation and integration solutions that have been developed by
customers and employees and posted to the Toolbox.
Authenticating to Halo and retrieving user or server information
Any client that uses the API must first authenticate to the Halo API's "Authorization" endpoint by providing the Halo
account's API key, and then submit the returned session token when making each API call. This ensures constant
API security.
The authentication method is an HTTPS POST call, as documented in the CloudPassage API Developer Guide . But
your software can use other languages to accomplish this task, as in this Python example:
connection = httplib.HTTPSConnection(host)
authstring = "Basic " + base64.b64encode(clientid + ":" + clientsecret)
header = {"Authorization": authstring}
params = urllib.urlencode({'grant_type': 'client_credentials'})
connection.request("POST", '/oauth/access_token', params, header)
response = connection.getresponse()
jsondata = response.read().decode()
data = json.loads(jsondata)
key = data['access_token']
...or as in this Ruby example:
client = OAuth2::Client.new(clientid, clientsecret,
:connection_opts => { :proxy => my_proxy },
:site => "https://#{host}",
:token_url => '/oauth/access_token'
)
token = client.client_credentials.get_token.token
After authenticating, your client could, for example, call the API's "Servers" endpoint to retrieve information for all
active Halo-protected servers, and then print out a list of server names before closing the connection. The call is
30
documented in the API Guide as an HTTPS GET request. In Python, it might look like this:
tokenheader = {"Authorization": 'Bearer ' + key}
connection.request("GET", "/v1/servers", '', tokenheader)
response = connection.getresponse()
jsondata = response.read().decode()
data = json.loads(jsondata)
# iterate through json result and print out hostnames
servers = data['servers']
for server in servers:
print server['hostname']
connection.close()
...or in Ruby, like this:
result = RestClient.get "https://#{host}/v1/servers", {
'Authorization' => "Bearer #{token}"
}
data = JSON result.body
servers = data['servers']
servers.each do |server|
puts server['connecting_ip_address'] + " " + server['hostname']
end
To examine the complete source code of these specific examples in the Toolbox, go to
https://github.com/cloudpassage/api_examples.
Exporting Halo events to third-party SIEM or log-management tools
The CloudPassage API includes an "Events" endpoint that clients can query to obtain complete information on all
Halo security events (for example, detected server configuration errors or file-tampering) within a range of dates. You
can use this capability to create an integration tool that feeds event data to a third-party tool for analysis.
CloudPassage has developed such a tool (the Halo Event Connector) and has made it available to customers. The
tool provides direct integration with Splunk Enterprise and SumoLogic, and integration through syslog to ArcSight and
other tools. For more information, see https://github.com/cloudpassage/halo-event-connector-python.
Other example API client code
Here are a few other code examples that you can examine by browsing through the Toolbox. They demonstrate a
variety of ways that you can exploit the power of the CloudPassage API to automate and streamline your serversecurity monitoring tasks.
Manipulating Halo server firewall policies
Two Ruby examples use the API to add a rule to a firewall policy and to modify a firewall policy's source or
destination IP zone.
Copying security policies and saving to archives
An example Ruby script downloads all firewall policies and file integrity policies for a Halo account, and formats
them as a report for use in auditing policy changes.
Discovering servers that have no installed Halo Daemon
An example script uses the Ruby fog library to retrieve all of your server IP addresses from cloud providers and
31
then cross-checks them against servers that have installed Halo daemons, to let you determine whether you have
any unprotected cloud servers.
Scanning servers within a group to detect differences among them
A script calls the "Server Issues" method of the Servers API endpoint for all servers in each server group in turn,
analyzes the results, and prepares a report for each group that summarizes how well the servers in the group
have the same consistent configuration status.
Detecting server-local accounts whose passwords should be changed
A script searches all of your Linux servers for local user accounts whose passwords are stale or expired and
should be changed. The script accesses the Servers API endpoint to examine all local accounts on all servers in
all server groups, then reports on any accounts whose last change date is older than the system-specified
maximum password age.
Identifying the IP addresses from which Halo users have logged into the Portal
This sample accesses the Events API endpoint and extracts the values of the user name, IP address, and country
of every Halo login event within the time range that you choose.
Besides browsing the Toolbox, be sure to consult the CloudPassage API Developer Guide and the Integrations forum
on the CloudPassage Support site to learn more about leveraging the CloudPassage API and integrating Halo with
your other tools.
PART 2
HALO ISSUES AND EVENTS
The security logging and alerting capabilities of Halo report on a broad range of important audit events and detailed
scan results. A Halo user specifies which issues are to be logged, which ones should be considered critical, which
should generate alerts, and who should receive the alerts that are sent. Given the flexibility and speed of Halo, you
can use server groups and alert profiles, along with a special events policy and scan results to create the right
alerting scenarios for rapid security response and compliance automation.
Topics:
Addressing Issues
Addressing Events
32
Halo reports important security occurrences or states regarding your servers in three forms—as issues, as events,
and as alerts. All three forms are closely related, although not identical.
An issue is a scan result—a detected software vulnerability, a failed configuration policy rule, or a changed file
integrity target. For configuration scanning and file integrity scanning, the rules and targets in your policies list the
violations that are to be considered issues. For vulnerability scanning, the current state of the NIST database
defines what software packages, if present, will be flagged as issues by Halo.
An event is a logged configuration or file integrity issue, or a detected software vulnerability or other special event
(as defined by your special events policy; see Set Up a Special Events Policy ). For configuration scanning and file
integrity scanning, you specify for each policy rule or target whether its violation should not only generate an issue,
but be logged as an event as well. For special events, you similarly specify for each potential event whether or not
you want it to be logged as an event. (Special events do not appear as issues.)
Audit events make up another class of events. They are user actions, such as logins to Halo or changes to a
policy, that are recorded for auditing purposes. By default all audit events are logged, but those settings are
configurable; see Audit Events.
An alert is an email notification sent to you or others to announce that a particular event has occurred. Alerts can
give your security personnel essentially immediate notice that an event, possibly critical, has occurred in your
servers or network. The details of the event are described in the alert so that immediate action can be taken.
For configuration scanning, file integrity scanning, and special events, you indicate for each specified event
whether it should also trigger an alert. (By default audit events are not alertable, but those settings are
configurable; see Audit Events.)
You can think of issues as casting the broadest net to capture potential security risks on your servers. The set of
events that you define can be just as broad (if you log every issue), or it can be somewhat more targeted toward
those issues that you feel are more likely to indicate a significant security problem. And the set of alerts you define
should be much smaller, restricted to the subset of events for which time-critical response is imperative.
Where do you go to view and address these occurrences?
You can view issues on an individual server's Scan Details page (accessed from the Portal Dashboard), on a
server's Scan History page (accessed from its Scan Details page), or on the general Server Scan History page
(accessed from the Servers menu).
You can view events on an individual server's Security Events page (accessed from the Dashboard) and on the
general Security Events History page (accessed from the Servers menu).
Alerts appear in the email in-boxes of the individuals (who do not have to be Halo users) who have been specified
as alert recipients.
Typically, there is a large overlap between issues and events. Most issues that you want to be reported should
probably also be logged as event , so you will mark them for logging. However, any rules or targets that you do not
mark for logging will appear as scan-result issues but will not appear as events.
The rest of Part 2 of this document describes how to set up, make use of, and interpret your issues, events, and
alerts.
In Halo, it is the responsibility of your organization to define
33
The specific set of configurations or occurrences that should be considered security issues.
The subset of issues that should be flagged as critical.
The subset of issues that should trigger events.
The set of other events that should be defined.
The subset of events that should trigger email alerts to appropriate personnel.
Even if you use the default security polices provided with Halo, you still need to make these decisions; some default
policies may not flag any issues as critical and may not mark any events to trigger alerts.
Flag Policy Issues for Logging and Alerting
When you create or edit a Halo security policy, you may be able to enable logging for individual rules in the policy.
Different Halo features handle event logging somewhat differently.
Configuration Issues and Events
While creating or editing a configuration policy, you can use the Log checkbox to specify for each rule whether it
should be logged:
You can also select the Critical checkbox if you want both the issue and the event to be considered especially
when displayed in a list. By default, critical issues/events
high priority. Critical issues or events are marked with
are sorted to the top of the list.
If you have elected to log an issue, then also select Alert if you want an alert to be sent as a result of the event's
occurrence. The alert is sent to all persons on the alert profile(s) assigned to the same server group that this rule's
policy is assigned to; see Set Up Alert Profiles for details.
File Integrity Issues and Events
If you are creating or editing a file integrity policy, note that there is no Log checkbox for a target; changes to
every target are reported as issues and also logged as events.
You can select the Flag Critical checkbox if you want the issue and event to be considered high priority and
in lists. You can also select Send Alert if you want an alert to be sent when the event occurs.
marked with
See Set Up Alert Profiles for information on specifying alert recipients.
34
Firewall Events
Halo server firewalls can generate logged events. Linux and Windows firewalls handle logging differently: On
Linux, you can turn logging on or off for each individual firewall rule; for Windows, only a few events are logged
and you turn logging on or off for a firewall policy as a whole.
The firewall events that you log do not by default become Halo events; they are not stored in the Halo database
and are not visible in the Halo Portal. On Linux servers, they are stored in the iptables logs , and on Windows
servers they are stored in the Windows Firewall logs. You can view the events with the appropriate system tools
for each platform.
Note: You can import selected firewall log events into the Halo event logging and alerting system by explicitly
scanning for them with the Halo Log-Based Intrusion Detection system. See next bullet.
Firewall events are not discussed further in this document. For detailed information on setting up Halo firewalls,
see Automating Server Firewalls With CloudPassage Halo .
Log-Based Intrusion Detection Events
You can use the Halo Log-Based Intrusion Detection system to leverage the existing system- and applicationlogging capabilities of your servers to capture events anywhere in your server fleet that may be indicative of an
intrusion or attack. When you create a policy rule to detect a specific event in a specific log file, you can specify
whether the occurrence of that event should logged by Halo, whether the event should be critical, and whether it
should generate an alert.
See Using Log-Based Intrusion Detection with CloudPassage Halo for more information .
Set Up a Special Events Policy
The Halo special-events alerting system notifies you of unusual occurrences in your cloud installation that may have
security implications. For example, if a server unexpectedly restarts, if its IP address changes, or if a firewall
configuration is changed outside of Halo, it could be a signal that something malicious has happened and you may
want Halo to log the event, and possibly alert you or others in real time. Also, all vulnerabilities detected by software
vulnerability scans are recorded as special events.
35
You set up special events by implementing a special events policy and assigning it to a server group. You can then
use the policy and an alert profile to customize alerting for any of the events.
Note: Halo automatically assigns the default Global Events Policy to every server group. However, that policy by
default generates no events or alerts, so you'll need to either customize the global policy or create a new
one for special events to be effective.
Take these steps to create a special events policy:
1. In the Portal, go to Policies > Special Events Policies and click Add New Special Events Policy .
2. Enter a name and optional description for the policy. Then select, from the available set of security events, the
specific events that you want this policy to monitor. If you want the policy to monitor a given event, check Log
event. If you consider the event critical, check Flag critical. If you want an email notification to be sent when an
event occurs, check Generate an alert .
A few of the events are marked as Linux-only and are not available for Windows servers.
Note: To help you decide which special events you want to monitor, it may be helpful to review the
discussion Act on special events , later in this document.
3. Click Save to save the policy. Then assign it to your server group—navigate to the Portal Dashboard page, click
Edit Details for your server group, and select your policy from the Special Events Policy drop-down list. Then
click Save.
Special-event logging is now set up for your server group. To complete the setup of logging and alerting, you'll need
to set up one or more alert profiles, as described next.
Set Up Alert Profiles
When Halo generates a certain type of event—specifically a logged issue or a special event—if the event is flagged
to generate an alert, a notification email is sent to a pre-specified set of Halo users. Every server group can have
different lists of users that receive alerts, and within each list different users can be selected to receive all events or
critical events only.
These lists are called alert profiles; you can create any number of them in the Halo Portal, and you assign one or
more to the server group appropriate for the persons on the list(s).
Note: If no alert profile is assigned to a server group, alerts will by default go to all Halo site administrators on
your account. You'll need to set up your own alert profiles if you want to control who receives alerts.
You might create different alert profiles for different server groups if, for example, you have different security
specialists monitoring each group. Or, create a profile just for managers and auditors, if you want them to receive
alerts much less frequently (say, once a week) than security specialists who must be prepared to respond
36
immediately.
To create and assign a new alert profile:
1. In the Halo Portal, go to Policies > Alert Profiles and click Add New Alert Profile .
2. Enter a name and optional description for the profile, and specify a batching frequency for sending alerts—from
"Instant" (to send each notification separately, as soon as the event is created) to "Every week" (to batch all
events for the week into a single email alert).
3. Select one or more of your company's Halo users, or one or more external recipients, to receive the alerts. Also
specify whether each user should receive all alerts or just a subset based on event criticality. Then click Save.
4. Assign the profile to a server group: On the Halo Dashboard page, click the name of the server group you want to
assign the profile to, then click Edit Details below the name. On the Edit Group Details page, select the name of
your new alert profile from the Alert Profiles drop-down list. Then click Save.
That's it. Your designated users will receive an email when a security event that fits your settings occurs. And you
can repeat this procedure to create other alert profiles for other server groups.
Addressing Issues
Reviewing the results of a Halo scan involves examining all reported issues in sufficient depth to determine which
ones represent valid security risks. You then can take appropriate action to address the valid risks—and you may also
take other actions to eliminate or suppress the invalid ones from future scan results.
View a Server Group's Summary of Issues
The Dashboard pages in the Halo Portal are server-group summary pages. For the selected Halo feature (for
example, Configuration risks) and for the selected server group, the page lists all servers in the group and
37
summarizes each server's status in regard to that feature.
Some items on the Server Group Summary pages are common to all or most Halo features:
Search. Lets you search for any server in the group by name. You can also find servers by browsing the
paginated server list or by re-sorting the displayed columns.
Actions. Lets you move selected servers or start a manual scan; see Maintain and Manage Your Servers and
Manually Scan Selected Servers .
Server/OS/Daemon Status. These columns name each server in the group, indicate its operating system, and
give you the status of its Halo Daemon: "Active" (the Halo Daemon has recently communicated with the Halo
Grid), "Deactivated" (the server was shut down or the Daemon was stopped), or "Missing" (Daemon-Grid
communication has been interrupted).
These controls and columns can help you to locate a server and identify servers that have shut down or crashed. The
two columns to the right of Daemon Status are Halo feature-specific, and help you to find servers and server groups
on which Halo has detected security issues:
For Configuration, File Integrity, Vulnerability, and Log-Based Intrusion Detection scans—
Critical. The number of critical issues found in the latest
scan, as defined by the policy used or—in the case of
software vulnerability—the vulnerability score compared
to the CVE vulnerability threshold. You may want to
address critical issues first.
Other. The number of non-critical issues found in the
latest scan.
To view details of the critical and non-critical issues found on any of these servers, click the number in the
or Other column for the server you choose.
For Server Access—
Root/Total Accts . The number of local accounts with
root privileges found in the most recent scan, and the
total number of local accounts found.
Last Root Login. The date-time of the most recent
login of any of the root-level accounts on this server.
Unexpected root logins may indicate suspicious activity.
38
Critical
To view details of all of the local accounts found on any of these servers, click either number in the
column for the server you choose.
Root / Total
For Firewall Management—
Firewall Status. The current status of this server's
firewall (
if the server has a firewall,
if not).
Policy. The name of the firewall policy assigned to
this server's server group. Click the firewall policy's
name to view or edit the policy details.
To view summary information and current status for the firewall policy assigned on any of these servers, click the
icon in the Firewall Status column for the server you choose. To view events triggered by firewall changes
outside of Halo, see your individual server's system firewall logs. (Or activate a firewall special event.)
If you have clicked the appropriate link, the server's Scan Results or Server Details page appears, as described in the
next section.
Analyze a Server's Current Issues
When you click the appropriate link for a server on the Dashboard, or the More detail link on a Server Summary
page, the Scan Results or Server Details page opens, displaying detailed information for that specific server and Halo
feature.
Some items on the Scan Results or Server Details pages are common to all or most Halo features:
Navigation links. Click the center link ("Web-27" in the above example) to jump to this server's Server Summary
page (see About the Server Summary Page ), which summarizes the server's status across all Halo features.
Trend graphs. Use these sparkline graphs to note spikes and to interpret general trends in the number of issues
reported for this server and this Halo feature, across various time ranges.
Scan metrics. For scans, lists the timing and status of the most recent scan. You may see these status values:
"completed": The scan was successful, and (for a configuration scan) no rule checks failed.
"completed w/errors": The scan was successful, some rule checks failed. (Applies to configuration scans only.)
39
"failed": The scan was not successful.
Policies used. Lists the policies that are currently in force or were applied to the most recent scan. Click the
name of a policy to view or edit its details.
Get PDF Report (action). Display a PDF version of this page to use as a report. You may save or print it as you
wish.
Server Scan History (action). Examine the Scan History page for this server (see To view an individual server's
scan history) to review the history of any issue in this scan. (For example, is it a new occurrence? A recurrence?
When was it first reported?)
This icon (
) appears beside issues of critical severity. You can sort the list of issues so that all critical ones
are displayed at the top.
Other information, table columns, and links on the page are Halo feature-specific, as shown below:
For Configuration Scans—
This is the expanded view of one issue:
A configuration issue is a policy rule failure, which is a failure of any check in the rule. The above results show
that one check failed and one passed in the rule "Disable IP Routing" in the policy "Amazon AMI". Therefore,
the rule failed.
Click a failed or passed check to further expand the display, and see exactly what happened—what setting was
tested, what value was expected, what value was found, and (optionally) what remediation steps are
recommended. From this info you may be able to infer whether this is a valid security issue that you need to
address.
If you think that this is not a valid set of rule checks in this situation, you can either (1) click Disable this rule
so that this issue will not occur in future configuration scans or (2) disable the individual failed check on the
Edit Policy page, so that it will not be used in the rule during future scans.
For more information on interpreting configuration scan results, see View and Act on Scan Results in Monitoring
Server Configuration Security With CloudPassage Halo .
For File Integrity Scans—
This is the expanded view of one issue (on a Windows server):
40
A file integrity issue is reported whenever a policy target has changed through alteration of its content,
ownership or permissions, or when a subdirectory or file has been added to or removed from a directory target.
The above results show that the target file sethc.exe has changed in these ways:
Its ownership has changed, from "NT SERVICE\TrustedInstaller" to "BUILTIN\Administrators".
The access permissions on it have changed ( red = added permission; green underlined = unchanged
permission; red lined-through = removed permission).
Its content has changed, as shown by the changed value for the cryptographic signature of the file.
Based on your understanding of the file and what its ownership and permissions should be or have been, and
whether or not the changes are suspicious, you may be able to infer whether this is a valid security issue that
you need to address.
If you think that this change is not a serious issue for this server at this time, either click Add Exception to
temporarily hide the issue from future scan results, or click the file integrity policy name ("malware detection" in
the above example) to edit the policy to remove the target or add an exclusion to it.
For more complete information, see Specifying Exceptions or Using Patterns to Create Inclusions and
Exclusions in Monitoring Server File Integrity With CloudPassage Halo .
If you want to inspect the baseline server that created the most recent baseline for the policy that triggered this
issue, click the server name ("AMAZONA-0" in the above example) to view that server's summary page. Also,
you can inspect the baseline report for that server (and other baseline servers, if there are more than one) on
the file integrity policy's Edit page.
For more information on interpreting file integrity scan results, see View and Act on Scan Results in Monitoring
Server File Integrity With CloudPassage Halo .
For Software Vulnerability Scans—
This is the view of one issue:
Package and Version. If you know that vulnerabilities in this package are not of concern to you (for example,
your installation might never use the package), you can click Add Exception to temporarily remove this issue
from future scans. If you will never use the package, the best solution may be to remove it from your servers.
41
Remotely Exploitable. "Yes" if the attacker can exploit vulnerabilities in this package without having local
access to the server. Remotely exploitable vulnerabilities could carry higher risk than those that are not.
View Full Report (with Passes) (action). Get a PDF version of this page that also lists non-vulnerable
packages.
Launch New Scan (action). Immediately run another vulnerability scan. You might do this if you have just
defined several exceptions and want to verify that those issues do not show up in the new scan.
CVE Reference. Click any of the CVE IDs in this line to view details of each individual vulnerability:
This information is from NIST. For more information on interpreting a CVE entry, see View Vulnerability Details
in Assessing Software Vulnerabilities With CloudPassage Halo .
Based on how your organization uses the vulnerable package and your understanding of the vulnerability from
the CVE report, you may decide to: patch the package immediately; protect the package in another way (such
as by changing firewall rules to prevent communication with it); or ignore it by creating an exception.
For more information on interpreting and remediating vulnerability scan results, see Interpret Vulnerability Scan
Results in Assessing Software Vulnerabilities With CloudPassage Halo .
For Server Access Scans—
This is the view of one local account found on the server, followed by the expanded view (from clicking
Account Details):
Expand
Username, Root Privilege, UID and GID and Groups. If you do not recognize this user, or if the user does not
need access to this server, investigate or deactivate the account. You can immediately see whether the account
has root privileges ("Yes" under Root Privilege or "0" under UID or GID), or whether it belongs to groups with
elevated privileges.
42
Home and Shell. Shows you whether the account has a home directory and where it is, plus what shell it uses
to access the server.
Last Login. Shows you how active this user is. If the last login was long ago, you might want to deactivate the
account. If the account user is an ex-employee but has logged in recently, you should investigate and
deactivate the account immediately.
Password Details. Lets you know whether the password has expired. If so, is this account still needed?
Sudo Access. Describes the kind of sudo (temporary superuser) privileges that the account has. High
privileges (such as in the above example) might merit investigation.
SSH Info. If the account has SSH privileges to this server, make sure that the ACL on the SSH directory is
appropriately secure (such as in the above example). Also, any authorized SSH keys are listed here.
Also use the "View All Accounts on ServerName" page to compare all of the local accounts on a server at a
glance. Use it to look for issues like unexpected accounts, unexpected logins, or indicators of elevated privilege
(such as membership in the "wheel" group) on the server.
Likewise, use the "View AccounName On All Servers" page to instantly compare accounts with the same name on
all servers in a server group. The account's information should mostly be identical across all servers in a given
server group; any differences might be cause for investigation.
For more information on interpreting and remediating server access scan results, see Managing Server Accounts
With CloudPassage Halo.
For Log-Based Intrusion Detection Scans—
There is no server scan-results or server issues page for Log-Based Intrusion Detection scans. All scan results
are already events, so clicking the number of critical or other "issues" on the server-group summary page causes
the Server Events History page to appear, displaying by default all log-based intrusion detection events captured
by Halo over the past 24 hours.
For each displayed event, the page indicates the event's criticality, lists its date-time of occurrence, indicates
which policy rule was matched, provides a link to the policy, and shows full text (or XML) of the event message.
If you think that a particular event is not a serious issue at this time, you either ignore it or you can click the logbased intrusion detection policy name ("windows logs" in the above example) to edit the policy to remove, disable,
or modify the rule.
43
If you think the issue may be serious, you may—based on your perception of its criticality—either investigate it
further on your own or launch an official investigation, as noted in Act On Reported Events .
For more information on interpreting log-based intrusion detection events, see Responding to Alerts and
Addressing Events in Using Log-Based Intrusion Detection with CloudPassage Halo .
About the Server Summary Page
Whenever you are viewing any of the Server Details pages described above, you can optionally jump to a page that
summarizes at a glance the server's status and configuration for all Halo features.
At the top left of the Server Details page, click the server name in the navigation links:
The Server Summary page appears, displaying a section for each configured Halo feature for that server. Links in the
sections take you to more detailed information.
Note: The Server Summary page is also the page that you jump to whenever you click the name of a server in
the server list on the Halo Dashboard page, regardless of which server group or Halo feature is selected.
View the History of an Issue
For configuration scans, file integrity scans, software vulnerability scans, and server access scans, the Server Details
44
pages always show the results of only the most recent scan. If you have a Halo NetSec or Professional subscription
plan, you may be able to gain historical insight into any of your current reported scan issues by examining the results
of earlier scans.
For example, you might possibly narrow down the time of occurrence of a bad configuration setting or a file tampering
incident by finding the first scan that detected it. Or you might learn that one of your software packages that is now
reported as vulnerable was reported as "OK" in earlier scans—meaning that it contains a recently discovered
vulnerability.
In the Halo Portal, an individual server's scan history page lists all scans of all types for that one server. The Portal's
Server Scan History page lists all scans of all types for all of your Halo-protected servers. Here is how you can use
either of those pages to look at historical scans.
To view an individual server's scan history
1. On the Portal Dashboard, select a server group and click the appropriate feature icon (such as
configuration scans), then click the name of the server whose historical scans you want to view.
for
2. On the Server Details page, click Scan History to view the Scan History page for that server.
3. Locate a particular scan that is of interest—perhaps because it is immediately previous to the most recent scan of
the type you are interested in, or because it shows a significant increase in critical issues from even earlier scans,
or because errors occurred during the scan.
Note that the list is sorted by date, with the most recent at the top. Scroll through the list to look for earlier scans
of that type that may be of interest.
4. Make note of the scan's status, completed date-time, and number of critical and non-critical issues. Then click
Details to see the Scan Details page for that scan.
The details page for a historical scan is similar to the Scan Details page for the most recent scan, and you can, for
example, examine it to see whether an issue of interest that occurred in the most recent scan also occurred in this
historical scan, or what issues it detected that were not in earlier scans.
To view scan history for all servers
1. In the Portal, navigate to Servers > Scan History . The Server Scan History page appears.
45
2. To view only one kind of scan (for example, configuration scans), sort by the Scan Type column and scroll as
necessary to view those scans.
3. Locate a scan of interest from a particular server, and note its status, requested and completed date-time, and
number of critical and non-critical issues. Then click Details to see the Scan Details page for that scan.
The details page for a historical scan is similar to the Scan Details page for the most recent scan, and you can, for
example, examine it to see whether an issue of interest that occurred in the most recent scan also occurred in this
historical scan, or what issues it detected that were not in earlier scans.
Act On Reported Issues
A significant number of the issues or events reported from your scans may not be actual indicators of malicious
activity. Those you can either ignore or (preferably) take steps to clear them from future scans. For significant security
issues, you'll need to address the underlying security risk that caused the issue.
Act on reported configuration issues —
The reasons for remediating Halo-detected configuration issues include restoring your servers' compliance with your
organizations' security policies, and generally hardening them against attack.
To remediate an individual issue, you can either make the needed change to each of your servers individually, or
you may be able to make the change to your gold master image or server template, if you use one, and then reinstantiate all the affected servers from that updated master.
In most cases it is clear from the nature of the failed checks what needs to be done to remediate. In addition, the
core policies provided with Halo have, in most cases, detailed remediation suggestions.
In some cases it is not your server configuration but the policy rule that needs revising. You may need to revise or
deactivate some checks to make a rule apply more precisely to your specific server environment or configuration
standards. For detailed instructions on working with configuration rules and checks, see Create or Customize a
Configuration Policy in Monitoring Server Configuration Security With CloudPassage Halo .
The hoped-for result of remediation is a significant reduction in the number of issues found in your configuration
scans, and elimination of all critical issues.
Note: Whenever your standard server configuration changes significantly—for example, if you start using a
different app server application—you may need to update your configuration policy or apply a different
one.
Act on reported file integrity issues —
When an issue from a a file integrity scan appears to be non-serious, you can take one of the following indicated
actions to prevent it from appearing in future scans:
If the event occurred because the object changes often and you want to stop monitoring it, you can remove the
object's target or inclusion from your policy, or create an exclusion for the object within the target (see Defining
an Exclusion in Monitoring Server File Integrity With CloudPassage Halo ).
If the event occurred because the object was added, changed, or removed legitimately and you want to start
monitoring its new state, make the same object change to a baseline server and re-run the baseline scan.
If the event occurred for an object that you want to keep monitoring, but the change is currently not an issue—
for example, if the object is undergoing testing or is scheduled for upgrade—create an exception to suppress
the event temporarily. No policy change or re-baselining is needed.
If the event occurred because an object that you want to keep monitoring was changed, added or removed in
46
error, just restore the previous state of the affected server(s). No policy change or re-baselining is needed.
If none of the above conditions applies and it appears that the event may indeed indicate potential malicious
activity on the server, stop using the server, quarantine it (if your organization's policy requires that), and
immediately notify your incident response team or security forensics team.
Act on reported software vulnerabilities —
Following a scan that reveals potential software vulnerabilities in your servers, your first task is usually to apply all
known patches, bringing your servers up to date. Then you can take further steps to identify and remove any
apparent issues that do not constitute a real threat.
Apply the latest patches and re-scan
First, upgrade your operating systems and critical applications to include all the latest patches. Either patch your
gold masters and re-instantiate all your cloud servers from them, or use automation tools such as Chef, Puppet, or
RightScale to re-provision all your servers with the latest software.
After patching, re-scan your servers and analyze the remaining vulnerabilities as described next.
Delete unnecessary packages
Some of the vulnerabilities detected by Halo may be in packages that your organization does not use. For
example, common administrative tools supplied with many distributions may have vulnerabilities; if you do not use
those tools on the server, you should remove them. Delete them from all affected servers and from any goldmaster server templates that you use for creating new server instances.
Define exceptions
Halo may report software vulnerabilities in certain software packages that you do not need to remediate now. For
example:
You may have scheduled an upgrade or patch in the near future.
You may have a compensating control that circumvents or blocks the vulnerability. For example, if a
vulnerability were reported in httpd, but your firewalls already disallow any HTTP traffic to or from the outside,
the vulnerability is not a concern for you.
The vulnerability may appear to be valid based on the package version number, but in reality it already has
been patched with an updated package. (This situation can occur because vendors sometimes update a
package without actually changing its version number.)
You can keep those events from showing up in your future scans by defining a software exception for that
package.
Address remaining unpatched vulnerabilities
Once you have applied all known patches, removed vulnerable packages that you do not need, and created
exceptions to hide issues that do not concern you, what remains—if anything—is some number of vulnerabilities
for which no patch is currently available.
Handle those vulnerabilities by following the recommendations in your organization's security policies. You might
remove the vulnerable packages from your servers, or create compensating controls to protect the packages, or
simply wait for a patch to become available—whatever is required to minimize your organization's exposure to
software-vulnerability risk.
Act on reported server access issues —
Server access scans do not directly report security issues. However, by examining scan results, you can infer
whether issues exist that should be addressed.
When examining scan results on the Dashboard page or on the Server Details page:
47
Make sure that the reported number of root accounts (accounts whose UID or GID is zero) is not different from
what you expect; extra root-level accounts could be a strong security concern.
The total number of local accounts on a server should not be unreasonably large, and if the servers in the server
group are all instantiated from a server template, this number should be the same for all of the servers.
Note whether there has been any recent remote login activity on that server by one of its privileged accounts. If
there has and it is unexpected, it may be a security concern.
Check the list of accounts for any unexpected account names or accounts that should have been removed (for
example, from ex-employees).
Make sure there are no accounts with root privileges that shouldn't have them.
Make sure that only accounts that should have root privileges have a zero UID or GID.
Verify that only accounts that should have shell access to this server do have it, and verify that the permissions on
the account's SSH directory are secure enough.
The date and time of the last login to this server from an account, along with the IP address of the remote machine
from which the user logged and the terminal that was used, can indicate whether the login was recent, whether it
occurred outside of normal business hours, and whether it came from an unexpected location.
Ensure that accounts that should be inactive are not active.
Verify that only accounts that need elevated privileges belong to groups (such as "wheel") with elevated privileges.
Verify that each account has only the appropriate sudo privileges for that account, and no more.
Note whether any of the accounts' passwords have changed recently and unexpectedly.
Based on any issues that you discover with any of the accounts, you can then take action:
Deactivate. If the account is not needed or belongs to someone who has left the organization, deactivate it. If the
account belongs to an unknown user, investigate immediately.
Edit or Create New Account. If the account has unnecessarily high privileges, needs changes to its group
memberships, or otherwise needs to be altered, you can edit its information. If the privilege escalation is
unauthorized, it may warrant immediate investigation.
If you want to restore an account that was inadvertently deleted, you can add it as a new account on the server. If
the account deletion is suspicious or appears to have been malicious, investigate immediately.
Launch New Scan. Immediately run another server access scan. You might do this if you have just edited,
created, or deactivated some accounts and you want to verify that your edits are reflected in the new scan.
Addressing Events
You review Halo security events by by viewing the "Security Events" Dashboard page on the Halo Portal, by
performing filtered searches for events on the Portal's Security Events History page, or by responding to email alerts
that you receive.
You should examine each event in sufficient depth to determine whether it represents a valid security risk. You then
can take appropriate action to address the risk if it is valid—or you may take a different action to prevent an invalid
event from being generated or sent as an alert.
48
View a Server Group's Summary of Events
To view the most recently generated events for a server group, click the Events icon (
or navigate to Servers > Security Events . Then select the server group of interest.
) on the Halo Dashboard,
This page summarizes the total number of critical and non-critical security events (not including audit events) for each
server in the selected server group. You can sort the display by any of the columns in the table.
Like the Dashboard pages for other Halo features, this page also lists the server platform and the Daemon status,
and it allows you to take various actions on a set of selected servers, as described in View a Server Group's
Summary of Issues and Maintain and Manage Your Servers .
You can see at a glance which servers in the group have had significant security events. Click the number of critical
or non-critical events for a server (in the Critical or Other column) to get more details (next).
Analyze a Server's Most Recent Events
Clicking the number of a server's events in the Dashboard's Security Events table displays that server's Security
Events Details page.
This page displays a server's most recent file integrity scan events, configuration scan events, and Halo special
events. (Audit events do not appear on this page.)
The event type, time of creation, and details appear in the line for each event. You can also link to the details of the
policy involved.
49
Based on an event's criticality, type, creation time, and path, you may be able to determine whether it represents a
valid risk that merits further investigation.
Filter and View a Server or Group's Event History
1. Navigate to the Security Events History page, at Servers > Security Events History .
2. Filter the display as necessary:
Specify one or all server groups, and one or all individual servers within your specified group.
Specify a date range for the events.
Choose one or more event types to view:
To view only file integrity scanning events, choose any of "File Integrity object added", "File Integrity object
missing", and "File Integrity object signature changed". These event types occur when a file has been
removed from or added to a directory target in a firewall policy, or when a change has occurred to any
target's contents, ownership, or permissions.
To view only configuration scanning events, choose "Configuration rule matched". This event type occurs
whenever a check in a configuration policy rule fails, which can occur in many ways—see Configuration
Policy Rule Checks for details.
To view only Halo special events, choose from among the special events that are marked for logging in your
currently applied special events policy—for example, "Daemon compromised" or "Server firewall modified".
To view only audit events, choose from among the many remaining event types. See Act on audit events for
a list of them.
Specify the server operating system(s), and whether you want to see only critical, only non-critical, or all
events.
3. Click Filter to display the filtered list.
You can sort the resulting list of events by criticality, creation date, event type, server group, and server, to display
the events of most interest to you toward the top of the list.
50
You can interpret the events in these ways:
Interpret configuration scanning events in the same manner as configuration issues; see For Configuration Scans
(under Analyze a Server's Current Issues).
Interpret file integrity scanning events in the same manner as file integrity issues; see For File Integrity Scans
(under Analyze a Server's Current Issues).
Interpret Halo special events according to their individual significance, as discussed in Set Up a Special Events
Policy.
You can take action to address these events as described in Act On Reported Events (next).
Act On Reported Events
The actions you can take to address an event depend on what sort of event it is.
Act on scan events:
Configuration events. If the event type is "Configuration rule matched", act on the event as you would a
configuration issue. See Act on reported configuration issues .
File integrity events . If the event type is "File Integrity object added", "File Integrity object missing", or "File
Integrity object signature changed", act on the event as you would a file integrity issue. See Act on reported file
integrity issues.
Log-based intrusion detection events . Evaluate the seriousness of the event and decide what action is most
appropriate:
Immediately quarantine the server involved and launch an incident response investigation
Take some less drastic action, such as notifying your security team of its occurrence, or initiating further
investigation through your organization's log-management or SIEM capability
Contact personnel involved with the event to determine whether it should be a security concern
Ignore the alert, because you know, based on other information, that it is benign
Alter your log-based intrusion detection policy so that this event will not be reported in the future, because
you know that it will always be benign.
Act on special events:
Firewall events . If the event type is "Server firewall modified", an individual server's firewall has been changed
outside of Halo. If you know of or approve of the change, either re-assign the firewall policy to the server group to
restore the proper firewall, or modify the group's firewall policy to make it consistent with the server's new state. If
the change was not approved or known of by anyone in your organization, start an investigation.
51
Software vulnerability events . If the event type is "Vulnerable software package found", act on it as described in
Act on reported software vulnerabilities .
Server account events. If the event type is "Multiple Root Accounts Detected", verify the event by performing a
server access scan on the server in question. If there are indeed multiple root accounts and this violates your
organization's security policies, either delete the extra accounts or start an immediate investigation.
Daemon security events . If the event type is "Daemon compromised", the Halo Daemon on a server has failed its
self-verification test (see Daemon Settings). A new Daemon must be re-installed before the server can be used
again. If the cause of the failure is unknown and may be suspicious, start an immediate investigation.
Audit-type special events . Other special events do not themselves constitute direct evidence of a security
problem or risky occurrence, but—like the general category of audit events described next—they may provide
supporting evidence to the forensics or incident response team investigating a potential server compromise. They
also are useful for generating documentary evidence of compliance with various security policies or standards.
Examples of this type of special event include "Server retired", "Server IP address changed", "Local account
created", and "Daemon version changed". To generate a report for compliance purposes, filter for an appropriate
set of these types of special event on the Security Event History page, pick a date range and other parameters,
and click Filter.
Act on audit events:
Halo defines a large number of security events that, for auditing purposes, are always logged and can be displayed
on the Security Events History page of the Halo Portal. Over 80 event types are captured, within the following
categories:
API Keys (4): Created, deleted, modified, secret key viewed
Authorized IPs (1): Modified
Automatic file integrity scans (3): Disabled, enabled, schedule modified
Configuration policy (7): Assigned, created deleted, exported, imported, modified, unassigned
File integrity baseline (4): Created, deleted, expired, failed, re-baseline
File integrity (2): Exception created, exception deleted, exception expired, scan requested
File integrity policy (7): Assigned, created, deleted, exported, imported, modified, unassigned
GhostPorts (4): Login failure, login success, provisioning, session close
Halo firewall policy (5): Assigned, created, deleted, modified, unassigned
Halo login (4): failure, success, logout
Halo password (4): Changed, recovery request failed, recovery requested, recovery success
Halo session (1): Timeout
Halo user (10): Authentication modified, deactivated, invited, modified, reactivated, re-invited, authentication
settings modified, account locked, account unlocked, activation failed
Server (1): Firewall restore requested,
SMS (1): Phone number verified
The records of these events may provide supporting evidence to the forensics or incident response team investigating
a potential server compromise. Audit events are useful also for generating documentary evidence of compliance with
various security policies or standards.
To generate a report for compliance purposes, filter for an appropriate set of these types of audit event on the
Security Event History page, pick a date range and other parameters, and click Filter.
52
APPENDIXES
Topics:
A. Halo Site Administration
B. Two-Factor Authentication
C. Search Expression Syntax
A Halo Site Administration
(For Halo site administrators only)
If you are a Halo site administrator, you are the user (or one of the users) responsible for managing your
organization's Halo service. Your responsibilities include management of Halo users, authentication settings,
automatic scan configurations, API keys, Halo Daemon settings, Master Account connections, and other advanced
settings.
You access all of these tasks from the Site Administrator menu (the gears icon
header).
in the Halo Portal page
Note: This appendix is a reference to the Halo Portal Site Administration page. Each subsection here describes
(or links to the description of) one of the tabs across the top of that page.
Users
See Invite and Manage Halo Users .
53
API Keys
In Halo, API Keys are required for using the CloudPassage API. Accessing the API requires the client to first
authenticate to the authorization server by providing a valid API key. (See Call Authentication in the CloudPassage
API Developer Guide for details.)
Halo site administrators can create and manage API keys. CloudPassage recommends that you create different API
keys for different purposes—in particular, you should create a read-only key to use for programs that only read from
(and do not write to) the Halo database. For example, applications that use the Halo Event Retrieval API should use a
read-only key, since that key allows only GET requests from the API.
Each Halo account initially has no API keys. If you are a site administrator, you can generate any number of API keys
as needed. For example, you might generate a separate API key for each application that accesses the API
To view or create API keys for your account, select Site Administration from the Site Administrator menu, then click
the API Keys tab. Your current set of keys is displayed on the tab.
To create a new API key, click Add New Key, then enter a name for the key and specify its permission level (fullaccess or read-only).
Specify allowed IP addresses . Optionally, for increased security you can enter a comma-separatted list of one or
more IP addesses or CIDR blocks. If you do so, an API client using this API key will be permitted to authenticate
to the Halo API only from one of the specified addresses.
54
The key's 8-character ID and secret key values are generated by the system, and the key appears in the list on
the API Keys tab.
Note: Every time a secret key is generated, the action is logged and the user who created the key is
identified.
To edit a key in the list, click its name. You can change the key's name and permission level (full-access or readonly), and you can activate or deactivate it.
To view the secret key value, click Show on the Edit API Key popup window or in the key's line on the API Keys
tab.
You'll need to copy the secret key's value from this window and use it to obtain an API token, which allows you to
access the CloudPassage API (see Call Authentication in the CloudPassage API Developer Guide ).
Note: Every time a secret key is viewed, the action is logged and the user who viewed the key is identified.
On the API Keys tab, use the Actions drop-down menu for a given key to either edit or delete the key.
Note: Every time an API key is deleted, the action is logged and the user who deleted the key is identified.
Authentication Settings
To minimize the potential for damage from stolen, intercepted, copied, recycled, or guessed passwords, you can
specify various requirements and settings for passwords and for login control.
Select Site Administration from the Site Administrator menu, then click the Authentication Settings tab.
55
Password Settings
Password Construction Rules . You can increase the minimum required password length from its default
minimum of 8 characters. You can also require that every password must contain at least one number, or one
symbol, or both (in addition to both uppercase and lowercase letters). If you choose to require symbols in
passwords, the following are supported:
()`~!@#$%^&*-+=|\{}[]:;"'<>,.?/
Password Expiration. You can enable password expiration and set the maximum lifetime (time to expiration) of a
newly created password to any number of days from 1 to 365.
You can also enable and specify the minimum lifetime of a newly created password (time that it must remain in
effect before it can be changed again) to any number of days from 1 to 999.
These two settings are independent. You can enable one or both or neither.
Login Settings
User lockout. You can change the failed login limit (number of consecutive times a user can attempt to log in until
the account is locked to prevent further login attempts) to any value from 1 to 25. Default value = 10.
You can also change the duration of a lockout to any number of minutes from 5 to 1440 (24 hours). Default
value = 60.
Note: For a locked-out user to log in again, the user can either complete a password reset (from the Halo
Portal login page) or wait until the lockout period ends.
Idle session timeout . By default, the timeout for Halo Portal sessions (the time after which an idle session logs
out) is 30 minutes. But you can keep idle sessions open for much longer, or you can cut them off more quickly.
Use drop-down list to choose a timeout value of as little as 15 minutes up to as much as 24 hours.
56
Multi-factor authentication for Halo login .
As a site administrator, you have the option of requiring Halo users to use two-factor authentication when logging
into the Halo Portal.
Two-factor authentication to the Portal is optional, but it is all-or-nothing—if you choose to activate it, it must apply
to all Halo users in your account. To activate the requirement, select the checkbox Require multifactor
authentication for Halo Portal logins .
You cannot activate two-factor authentication for Portal login until all Halo users on your account have been
individually enabled for multi-factor authentication. Once it is active, all newly created users must also be enabled
for multi-factor authentication.
When two-factor authentication for Portal login is active:
A new user logging into the Portal for the first time is initially brought to the Change Password page to create
the user's Halo password. The user is then brought to the either the SMS Phone Verification page to enter an
SMS verification code, or the YubiKey authentication page to insert a YubiKey. Then the user may log in in the
same way as an existing user.
A existing user logging into the Portal initially provides the Halo password at the login page, and then enters an
SMS authentication code (or inserts a YubiKey) at the multi-factor authentication page. (A user enabled for
both types of authentication first chooses which method to use.) The user is then logged in.
57
For more details, see Log In With Two-Factor Authentication .
Single Sign-On Settings
If you are implementing an integration of Halo with your organization's SAML 2.0-based single sign-on solution, you
may need to develop a plug-in or application according to the identity provider's requirements, so that the proper
SAML assertions are sent to Halo to perform the authentications. Or the identity provider may have already created
the integration app for Halo.
Part of setting up the integration involves enabling single-sign on and entering information into fields in the Single
Sign-On Settings section of the Authentication Settings tab on the Site Administration page
1. Select the Enable Single Sign-On (SSO) check box. The section expands to display the single sign-on settings
form.
2. Copy the account ID from this form and supply it to the SSO identity provider.
3. Obtain information to enter into the remaining fields from the identity provider.
4. Make SSO Required . If you want to disallow all direct logins to the Halo Portal, select this checkbox at the bottom
of the form. If you do select the box, you must provide SSO access to all existing and future Halo users. Note that
you cannot select the box unless you are currently logged in through SSO.
Note: As long as this checkbox remains selected, Halo users' account pages have no displayed password
field, Halo users cannot reset their passwords, and new Halo users do not receive email invitations to
log into Halo.
5. Click Save to commit your SSO settings.
For detailed instructions on creating the SSO integration, see Adding Single Sign-On to CloudPassage Halo .
58
Scanner Settings
See Configure Automatic Scans.
Daemon Settings
As site administrator, you can control various settings for the Halo Daemons currently running or to be installed on
your servers.
Select Site Administration from the Site Administrator menu, then click the Daemon Settings tab.
Daemon Registration Key . A valid key is needed whenever you install a Halo Daemon (see Install Daemons).
You can use the same key value for all installations, as long as it remains confidential. If you feel that it might have
been compromised, click Regenerate to get a new key, and use that one in future installs.
Daemon Heartbeat. For security reasons, all communication between a Halo Daemon and the Halo Grid is always
initiated by the Daemon. The Daemon connects to the grid at regular intervals to report status and to receive
instructions. You can select an interval from 60 seconds to15 minutes. Default value = 60 seconds.
If you have a large number of servers, selecting a longer interval may have the benefit of less impact on your
network performance, although Halo updates and commands sent to your servers may take longer.
Deactivate Missing Servers . 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. To keep missing servers that do not re-contact the
Grid from remaining in a missing state perpetually, Halo will automatically delete them after a time interval that you
specify.
Use the drop-down list to select the threshold for auto-deactivation to any available value from 15 minutes to 24
hours.
59
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.
Daemon Self-Verification . The Daemon can continually monitor itself for evidence of compromise and report any
evidence that it has been tampered with. You can enable or disable self-verification, you can choose to have
compromised Daemons shut themselves down automatically, and you can set the interval between self-verification
checks to any number of hours from 1 to 23. Default = 1 hour.
Advanced Settings
A variety of other Halo settings are available to site administrators. To review or change them, select Site
Administration from the Site Administrator menu, then click the Advanced Settings tab.
Set GhostPorts Session Length:
Set the length of time that a server administrator will have to log into a server after turning on GhostPorts. Select a
number of hours from 1 to 24. Default value = 4.
A longer time window may be more convenient for an administrator, but it may be riskier (less secure) than a
shorter one.
List IP Addresses Authorized to Access Halo Portal:
For added security, you can specify that your Halo users (including yourself) are permitted log into the Halo Portal,
or request a password reset, only from identified IP addresses.
Enter a comma-separated list of IP addresses or CIDR blocks into the IP Addresses field.
Note: The list of authorized addresses must always include (or encompass) the address from which you are
60
accessing the Portal in order to create or edit the list.
To remove all address restrictions for logging into the Portal, delete all addresses from the field and click
Save.
Choose Your Email Preferences
Pick a time of day and a time zone to specify when Halo should send out its daily status emails to the Halo users
in your account.
Note that individual users can choose whether or not to receive daily status emails; see Manage Your Account
and Subscription .
Enable Halo Beta Features
CloudPassage may release some Halo features or capabilities when they are still at the beta stage of
development. In some cases the features are by default disabled. If you want them to be available to your Halo
users, select the Enable Beta Features checkbox. Conversely, clear the checkbox to make the features
unavailable.
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.
Halo site administrators can use the Audit Events tab on the Site Administration page to specify which events should
be logged, which should be flagged as critical, and which should generate alerts.
61
For each listed event, select "Log Event" if you want Halo to record occurrences of the event, select "Flag Critical" if
), and select "Generate an Alert" if an occurrence should
you want those occurrences to be flagged as critical (
cause an email alert to be sent to the appropriate personnel in your organization.
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 various Halo policies.
Master Account
Your organization, with its own CloudPassage Halo account, may be one of several organizations that are part of a
larger entity (such as a parent company) that wishes to have oversight and control over all of its sub-organizations'
security operations. Halo supports this with the concept of master accounts.
A master account administrator has access to all of the sub-accounts through the Halo Portal, allowing the
administrator to review all sub-account settings and configurations, audit all actions and events in the sub-accounts,
and even directly manage and run their Halo activities. The administrator can operate within each sub-account as a
site administrator of that account.
If your account needs to be linked to a master account, you will have received a master account invitation code
from your master account administrator. Enter that code into the field on the Master Account tab of the Site
Administration page, and click Link to complete the connection to the master account.
If your account is currently linked to a master account and you need to sever that relationship, click the
Disconnect button on the Master Account tab.
62
If your organization wishes to connect to a master account, please contact CloudPassage Sales or your account
representative to have the master account created for you.
B Multi-Factor Authentication
For site administrators, this appendix details how to enable multi-factor authentication for Halo users. For Halo users,
it details how to log in with multi-factor authentication.
Enable Multi-Factor Authentication for a User
To enable multi-factor authentication for a Halo user, you must be a Halo NetSec or Halo Professional user with siteadministrator privileges.
Important: Enabling multi-factor authentication for a user will not take effect until you activate two-factor
authentication for the Halo Portal as a whole, on the Site Administration page; see Multi-factor
authentication for Halo login . Also, since two-factor authentication to the Halo Portal is all-ornothing, you will not be able to activate it until you have enabled it for all of your organization's
individual Halo users.
Before enabling:
If the user is to use SMS authentication, obtain that person's valid mobile phone number. Text messaging must be
enabled for that mobile account.
If the user is to use hardware authentication, acquire a YubiKey. You can order the keys directly from Yubico.
Then:
1. Log into the Halo Portal and navigate to [
] > Site Administration > Users .
If the person is not already a Halo user, click Invite New User .
If the person is an existing Halo user, find the user's name in the user list and click Edit.
2. Specify or change the user's information, including Portal access and user type, as described in Invite a New User
or Edit an Existing User . (You will be able to enable GhostPorts access for the user, if desired, only after enabling
multi-factor authentication for the user.)
3. Specify the user's authentication method(s): select SMS code and Halo Password or YubiKey and Halo
Password, or both.
63
4. The page then expands to display additional fields. Enter the following information:
If you selected SMS code and Halo password—
a. In the "Phone Number" field, enter the telephone number at which the user will receive the SMS authentication
codes. It must be a valid mobile phone account with text messaging enabled.
b. Click Save. The user receives an email notification of being enabled for multi-factor authentication and an
invitation to log into the Portal. At the next login, the user will be asked to verify the SMS phone number.
If you selected YubiKey and Halo password—
a. Place the YubiKey into a USB port on your computer, with the metal contacts and circle facing upward (
). Place your cursor into the "YubiKey Code" field on the page. Initiate the YubiKey by lightly touching the top
circle with the green centered light. The YubiKey key will write its complete key value into the field.
b. Click Save. You will notice a portion of the key value disappear. The first twelve characters of the key value will
remain displayed in the key field. The user receives an email notification of being enabled for multi-factor
authentication.
Log In With Two-Factor Authentication
If you are a Halo user who must use two-factor authentication to access the Halo Portal, or if you are a GhostPorts
user, follow the steps listed here to log in.
The login processes for SMS authentication and YubiKey authentication differ slightly. Also, SMS authentication adds
a one-time preliminary step of verifying the SMS phone number.
Verify Your Phone Number (for SMS Authentication)
If you will be authenticating to the Halo Portal with an SMS code, you first need to verify to Halo that the
authentication phone number assigned to you is the correct one. The verification process includes demonstrating that
the phone can receive a code from Halo.
1. After you receive your notification that you are enabled for SMS-based multi-factor authentication, log into the
64
Halo Portal with your Halo password. You will see a Dashboard banner notifying you that your SMS phone number
is unverified.
2. Click the link in the banner to go to the Phone Verification page for SMS authentication.
3. In the Verify Phone form, inspect the partially masked phone number, of the form XXX-XXX-XX 67. If the
displayed digits of the phone number are not correct, contact your Halo site administrator to change your assigned
number.
4. If the displayed digits match your phone number, click the Send Verification Code button. A code will be sent to
your mobile phone.
5. When you receive the message on your phone, copy the six-digit verification code into the Verification Code field
on the Verification page, then click Submit.
You have 5 minutes from the time you click Send Verification Code until the code expires. If you do not complete
this step within that time, you can click Send Verification Code again to have another code sent to you.
If the verification succeeds, a success page and banner are displayed. You are now able to log into the Halo Portal.
Authenticate With an SMS Code
Note: You must already have verified your phone number (see previous section, Verify Your Phone Number)
before you will be permitted to perform these steps.
If you are authenticating to Halo with an SMS code, follow these steps:
1. Log into the Portal with your Halo username and password. The Multi-Factor Authentication page for SMS
appears:
2. An SMS code has been sent to your mobile phone. When it arrives, enter it into the Authentication Code field and
click Submit.
You have 5 minutes from the time you click Submit until the code expires. If you do not complete this step within
that time, you can click Re-send Authentication Code to have another code sent to you.
Note: The code is sent by SMS, and normal text-messaging charges for your account may apply.
After you have authenticated successfully, the Portal Dashboard page appears, displaying a success banner.
Authenticate With a YubiKey
Note: You must be in possession of your assigned YubiKey device to perform these steps.
If you are authenticating to GhostPorts with a YubiKey, follow these steps:
1. Log into the Portal with your Halo username and password. The Multi-Factor Authentication page for YubiKey
appears:
65
2. Place your YubiKey into a USB port on your computer, with the metal contacts and circle facing upward (
).
3. Place your cursor in the blank field on the Multi-Factor Authentication page.
Initiate your YubiKey by lightly touching the top of the key on the green-centered light for about one second. Do
not press any other key on your keyboard.
You will see the field fill with the value generated by your YubiKey.
After you have authenticated successfully, the Portal Dashboard page appears, displaying a success banner.
Site Administrators: Set Up a Backup Authentication Method!
If you are a Halo site administrator who uses multi-factor authentication to log into the Halo Portal, you may need to
enable both SMS and YubiKey authentication methods for yourself, so that you can use one method as a backup in
case the other one becomes unavailable. Without a backup, you could permanently lock yourself out of access to the
Portal.
Whether you are a site administrator or standard Halo user, if you lose your mobile phone or your assigned YubiKey,
any other site administrator in your organization can log in and reset your authentication method to use a different
method or device that is available to you. However, if you are the only Halo site administrator in your organization and
you lose the assigned device, you will be unable to log into the Portal. In that situation, you will have to contact Halo
Customer Support and go through a lengthy identity-verification process in order to restore your access.
Our strong recommendation is that, if your Halo account includes only a single Halo site administrator, you enable
both of the two-factor authentication methods (SMS and YubiKey) for that administrator.
C Search Expression Syntax
Several Halo features (for example, the "string presence" rule check in configuration security monitoring, and policy
rules in log-based intrusion detection) support the use of search patterns. Halo search patterns are strings of plain
text, special characters, and metacharacters—very similar to regular expressions, although not as full-featured. This
appendix lists the special characters and metacharacters supported by Halo, describes what each one means, and
gives usage examples.
Note: All searches are case-sensitive.
66
Character
Represents
Usage Example
.
Any character
abc. matches abcd, abcZ, abc3, abc$, abc/...
\w
Any alphanumeric character
C\wPO matches CAPO, C3PO, CbPO...
\W
Any character that is not alphanumeric c\Wpo matches c@po, c#po, c%po...
\d
Any digit (numeric character)
C\dPO matches C3PO, C4PO, c0po...
\D
Any character that is not a digit
C\DPO matches CAPO, C@PO, CaPO...
\s
Any whitespace character
abc\sd matches abc d
\S
Any non-whitespace character
abc\Sd matches abc.d, abcCd, abc$d...
[ ]
One instance of any of the characters
inside the brackets
cloud[9Sy] matches cloud9, cloudS, Cloudy
[^ ]
Any character that is not one of the
characters inside the brackets
cloud[^9Sy] matches cloud8, CLOUD0, cloudZ...
*
Zero or more consecutive occurrences
of the previous character
cloud9* matches cloud, cloud9, cloud99, cloud999...
+
One or more consecutive occurrences
of the previous character
cloud9+ matches cloud9, cloud99, cloud999...
?
Optional presence of the preceding
character
555[-.]?1212 matches 555-1212, 555.1212, 5551212
\
Escape character (precedes a special
character)
Use \$ to match a dollar-sign character, or \. to match a period
(dot).
-
(hyphen) range operator
[a-d]loud[1-9] matches cloud9 (but also aloud1...)
^
The search expression must match at
the beginning of the target string (file).
^cloud will find a match in cloud9 but not in 9cloud
$
The search expression must match at
the end of the target string (file).
cloud$ will find a match in 9cloud but not in cloud9
Note: To use a special character as a literal character, be sure to precede it with the escape character, as in \for a hyphen.
Copyright ©2014 CloudPassage Inc. All rights reserved. CloudPassage ® and Halo ® are registered trademarks of CloudPassage, Inc.
67

Halo Operations Guide For Users of CloudPassage Halo

Transcription

Similar documents

Tips for using the Alioscopy Trigger for Adobe Photoshop Extended

Communication and Perception

one sheet Dark Halo

halo effect - EK Product

Halo by Parasound is the pinnacle of our 25 years` experience.

Silvia Dalnodar

Pellucid Marginal Degeneration

br than cotton breathes better than cotton

A 31 Three Channel Power Amplifier