Halo Issues, Events, and Alerts

Transcription

1 Halo Issues, Events, and Alerts Addressing Scan Results and Security Notifications The security logging and alerting capabilities of Halo record and report on a broad range of important audit events and detailed scan results. A Halo user specifies which issues are to be logged as events, 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: About Issues, Events, and Alerts Setting Up Logging and Alerting Set Up Alert Profiles Set Up a Special Events Policy Flag Policy Issues for Logging and Alerting Respond to Alerts Addressing Issues View a Server Group's Summary of Issues Inspect 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 Inspect a Server's Most Recent Events Filter and View a Server or Group's Event History Act On Reported Events Appendix: Interpreting File Access Permissions About Issues, Events, and Alerts Halo reports important security-related occurrences or situations in your servers in two forms as issues and as events. Also, Halo notifies you of these results in two ways as results reported in the Halo portal, and as alerts. These terms are are distinct but closely interrelated: An issue is a scan result such as a detected software vulnerability, a failed configuration policy rule, or a changed file integrity target. For configuration scanning, file integrity scanning, and log-based intrusion dettection scanning, the rules and targets in your policies list the violations that are to be considered issues. For vulnerability 1

2 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 issue or other special event (as defined by your special events policy; see Set Up a Special Events Policy). For configuration scanning, file integrity scanning, and log-based intrusion dettection 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 on the Site Admoinistration page of the Halo portal. An alert is an 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 also are configurable on the Site Admoinistration page of the Halo portal.) 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 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 this document describes how to set up, make use of, and interpret your issues, events, and alerts. Setting Up Logging and Alerting In Halo, it is the responsibility of your organization to define 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 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. 2

3 Set Up Alert Profiles When Halo generates an event, if the event is flagged to generate an alert, a notification is sent to a prespecified 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 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 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 when a security event that fits your settings occurs. And you can repeat this procedure to create other alert profiles for other server groups. 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 3

4 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. 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 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 event and audit 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. Repeat the process for other groups as needed. Flag Policy Issues for Logging and Alerting When you create or edit a Halo security policy, you may be able to enable logging, issue/event criticality, and alert triggering for individual rules in the policy. Different Halo modules handle event logging somewhat differently. Click the headings below to see the differences. 4

5 Respond to Alerts Once logging and alerting is configured, Halo's continual monitoring of your servers will result in events being logged and alerts being sent, as specified in your security policies. When Halo logs an event that a policy has flagged for generating an alert, you (or the appropriate administrators or security specialists specified in the server group's assigned alert profile) will receive an notification of the event, within a few minutes of its detection. The alert looks something like this: If you are the security specialist that receives the alert, follow the link in the to the Halo portal, where you can address the issue. 1. First, examine and interpret the specific nature of the event, as described in the issue-specific subsections of Inspect a Server's Current Issues. 2. Depending on the nature of the event and your judgment as to its severity or potential danger to your organization, choose one of several courses of action. See Act on Reported Events for specific suggestions. 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 summarizes each server's status in regard to that feature. 5

6 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 to another server group, delete them, or manually scan them. Server/OS/agent Status. These columns name each server in the group, indicate its operating system, and give you the status of its Halo agent: "Active" (the Halo agent has recently communicated with the Halo analytics engine), "Deactivated" (the server was shut down or the agent was stopped), or "Missing" (agent-engine 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 agent Status are Halo feature-specific. They help you to find servers and server groups on which Halo has detected security issues, as shown below. If you have clicked a link to view details for an individual server, the server's Scan Results or Server Details page appears, as described next. Inspect 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. 6

7 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.) "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 specific to each Halo module, as shown below. Click a heading to display the content. 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. 7

8 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 pages always show the results of only the most recent scan. 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 for configuration scans), then click the name of the server whose historical scans you want to view. 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 8

9 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. 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. See below. 9

10 Addressing Events Most security issues detected by Halo are logged and are therefore viewable as Halo events. Halo events include all logged security issues, plus all Halo special events and audit 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 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. 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 agent 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). Inspect 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. 10

11 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. 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 "File Integrity change detected". This event type occurs 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, "agent 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. 11

12 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. You can examine and interpret the events just as you would their equivalent issues. See: View an issue from a configuration scan View an issue from a file integrity scan View an issue from a vulnerability scan View a log-based intrusion detection event Interpret Halo special events according to their individual significance, as noted in your special events policy, See Set Up a Special Events Policy. You can take action to address any of 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-related 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. 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 if it were reported as an issue. See Act on reported log-based intrusion detection events. Software vulnerability events. If the event type is "Vulnerable software package found", act on it as described in Act on reported software vulnerabilities. (Note that even though this event type is scan-related, it is classified as a special event.) Server account events. If the event type is "Multiple Root Accounts Detected" or "Multiple accounts detected with same UID", verify the event by directly accessing the server in question. If there are indeed multiple root accounts or if any account's UID is not unique, and this violates your organization's security policies, either delete the extra accounts or immediately start an investigation. (This event type also is scan-related, but classified as a special event.) Act on special events and audit events: Firewall events. If the event type is "Server firewall modified", an individual server's firewall has been changed 12

13 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. agent security events. If the event type is "agent compromised", the Halo agent on a server has failed its self-verification test (see Agent Settings in the Halo Operations Guide). A new agent 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 "agent 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: Created, deleted, modified, secret key viewed Authorized IPs: Modified Automatic file integrity scans: Disabled, enabled, schedule modified Configuration policy: Assigned, created deleted, exported, imported, modified, unassigned File integrity baseline: Created, deleted, expired, failed, re-baseline File integrity: Exception created, exception deleted, exception expired, scan requested File integrity policy: Assigned, created, deleted, exported, imported, modified, unassigned GhostPorts (multi-factor network authentication): Login failure, login success, provisioning, session close Halo firewall policy: Assigned, created, deleted, modified, unassigned Halo login: failure, success, logout Halo password: Changed, recovery request failed, recovery requested, recovery success Halo session: Timeout Halo user: Authentication modified, deactivated, invited, modified, reactivated, re-invited, authentication settings modified, account locked, account unlocked, activation failed Server : Firewall restore requested, SMS: 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. A complete list of supported event types is available on the Audit Events tab of the Site Administration page in the Halo portal, and in the documentation for the Events API endpoint in the Halo REST API Developer Guide. 13

14 Appendix: Interpreting File Access Permissions Unexpected changes in a file or directory's access permissions can be indicative of an attack or intrusion. Halo displays the permissions for a changed file integrity target in a scan's event details, and also indicates whether the permissions themselves have changed. You can examine the permissions to determine whether a change to them is suspicious. Linux Permissions Every file and directory on a Linux system is owned by a user and by a group. Permissions for accessing that file are defined separately for the user, for the group, and for all others. "Other" is defined as a user that is not the owning user and is not a member of the owning group. Linux supports three types of access permission: read. For a file, the ability to open it and read its contents. For a directory, the ability to list its contents. write. For a file, the ability to modify it (write new data to it). For a directory, the ability to add, remove, or rename files within the directory. execute. For a file, the ability to execute it as a program or script. For a directory, the ability to make it the current directory (as with the cd shell command), and the ability to access files within it. Halo displays a Linux file or directory's permissions using the symbolic mode common to shell displays, with three sets of three single character symbols, specifying the permissions of the owner, group, and others, respectively. For example: In this example, the user owner has full permissions on the file, the owning group can read and execute the file but not modify it, and others can open and read the file, but not modify or execute it. Special Linux permissions. The above permissions string can include several additions or substitutions in special cases: Directory. If the file is a directory, the permissions string may be prefixed with d. For example: drwxr-xr-- setuid /setgid bit. If the executable file's setuid or setgid bit is set (meaning that the file will execute as the user owner or group owner, with the owner's permissions), s or S is substituted for r in in the "User" or "Group" permission. For example: swxr-xr-- or rwxs-xr-- Sticky bit. If a directory's sticky bit is set (meaning that no users except the directory's owner and the superuser can rename or delete files within the directory), t or T is is substituted for x in the "Others" (all users) permission. For example: drwxr-xr-t Windows Access Control Entries All Windows securable objects such as files and registry keys have security descriptors, which allow the system to determine whether access should be granted to the object. A security descriptor identifies the object's owner and contains, among other things, a discretionary access control list (ACL). The ACL is an ordered list of zero or more access control entries (ACEs). Each ACE specifies the type of access being addressed (allow, deny, audit), includes inheritance flags, identifies the principal (user or group) for whom this 14

15 access is specified, and contains an access mask that lists the operations that are allowed or denied to that principal. The access mask is represented as a 32 bit string; each bit location in the access mask represents a specific type of permission for the object. In file-integrity scan details, Halo represents an object's ACL as a sequence of text lines, one for each ACE that is, one for each principal with defined permissions on the object. In each ACE, Halo replaces the non-human-readable ACE bit mask with a series of multi-character codes specifying the permission details: These are values you might see for each of the ACE elements: Principal. This is the name of the user or group owner, preceded by a scope designation. The scope may be NT AUTHORITY, BUILTIN, the local domain (machine name), or Active Directory/LDAP domain. For local user accounts where the scope is the machine name, Halo replaces the machine name with "Local" so that events will not be created when local accounts on different machines differ only by the machine name. Inheritance. The inheritance strings can have these values and meanings: OI. Object inherit (applies only to folders and non-leaf registry keys) CI. Container inherit (applies only to folders and non-leaf registry keys) IO. Inherit only (applies only to folders and non-leaf registry keys) NP. Do not propagate the inherit (applies only to folders and non-leaf registry keys) I. Access control is inherited from parent container It is also possible for a file object to have no inheritance designation in its ACE. Type. The type of the access control entry can be either Allow or Deny. Permissions. The following are the rights that can appear in the permissions string in the Halo portal. Note that Halo displays only "specific rights," not the "simple rights" groupings that you may find using icacls or a similar tool. File or folder: AD. Append data/add subdirectory AS. Access system security DC. Delete child DE. Delete GA. Generic all GE. Generic execute GR. Generic read GW. Generic write MA. Maximum allowed RA. Read attributes RC. Read control RD. Read data/list directory REA. Read extended attributes S. Synchronize WA. Write attributes WD. Write data/add file WDAC. Write DAC WEA. Write extended attributes Registry key: CC. Create child CR. Control access DC. Delete child DT. Delete tree KA. Key all KR. Key read KW. Key write KX. Key execute LC. List children LO. List object RC. Read control RP. Read property SD. Standard delete SW. Self write WD. Write DAC WO. Write owner WP. Write property 15

16 WO. Write owner X. Execute/traverse Interpreting Colored Elements in a File Integrity Issue or Event In the more details display of a file integrity issue or event, colors indicate the nature of changed elements: Any file signature or critical metadata value that does not match the baseline is highlighted in red. Items that have been removed since the baseline scan are highlighted in red and lined-through. Items that have been added since the baseline scan are highlighted in green. Note that if permissions are added to or removed from a Windows object, the Permissions field in scan details may display other items twice once in lined-through red and once in green. This occurs because Halo examines the list in order from the top, and only items that have not changed in content or position remain black (unhighlighted) in the scanned object details. Any item whose position has shifted will appear twice, in green at its new position and in red at its old position. For example, in the scan details above, the first item in the list ("local\r9:...") was in the baseline scan but was replaced on this server with a different permission ("Local\QA:...") before the most recent scan. The remaining 3 items did not change their content or position in the list, so they remain black. The added item appears underlined in green at its appropriate point in the list, and the removed item appears after the list, lined-through in red. In another example of scan details (above), the first item in the list ("local\r9:...") was in the baseline scan but was removed from this server before the most recent scan. The remaining 3 items have changed position what was item two is now item one, and so on. Therefore the entire original list appears to have been removed (and is lined-through in red), and the server's entire current list appears to have been added (and is underlined in green). 16

17 Copyright 2015 CloudPassage Inc. All rights reserved. CloudPassage and Halo are registered trademarks of CloudPassage, Inc. 17