Table of Contents
|Note: This document is also available in other formats|
A PDF version of this document along with all current and older documentation in PDF format can be found at https://my.clavister.com.
It also available in a framed HTML version.
The Clavister InCenter cloud product is an administrative tool for the remote centralized monitoring of one or many NetWall systems using a Web User Interface (WebUI) running in a standard web browser. The browser connects to an instance of the InCenter server running in a cloud environment and the server then mediates communications between the WebUI and the NetWall systems. This is illustrated below.
Note that a NetWall system will be referred to generically as a node in the context of InCenter.
When a NetWall node is added to InCenter, it means that the node continues to be managed locally but InCenter is able to act as a log server that receives log messages from the node. The received logs messaged can then be analyzed using InCenter dashboards.
History Storage TimesThe following should be noted about the default length of time that the log messages data received from nodes are stored by the InCenter cloud service:
Complete log message data is retained for a period of 3 days.
Aggregated log message data is retained for a period of 30 days. This means that drill down to the log message level is not possible. However, the aggregated data can still be broken down by node or time range.
To extend these default time periods, contact your local Clavister sales representative.
The InCenter WebUI is a graphical interface that allows interaction with the InCenter server through a standard web browser. It can be used for performing a range of administration and monitoring tasks.
English (abbreviation: "en").
Japanese (abbreviation: "ja").
The WebUI language cannot be changed once the interface has opened. To switch language, the WebUI should be closed, the browser's default language changed and then the WebUI reopened.
Alternatively, the language can be selected by adding the parameter:
to the URL that opens the initial login page (it will not change the language mid-session, after login). The possible <language-abbreviation> values are given in the preceding language list.
For example, to open the login dialog in English:
To open the login dialog in Japanese:
Note that once the WebUI is opened with a particular language, it will open for the next session with that same language if no language parameter is specified in the URL. The language can only be changed by explicitly specifying the language parameter at the end of the URL.
The WebUI is available through any modern web browser. The only prerequisite is that the browser can access the InCenter server using HTTPS.
Connecting to the WebUIAfter opening a browser, the InCenter WebUI is started by entering the IP address of the InCenter server in the browser's navigation field.
Logging InAfter successful connection to the InCenter server, a login dialog will be displayed in the browser, as shown below.
Note that the second time the administrator logs in with these credentials, they will be prompted to change the password to one that conforms to the system's password policy settings.
The Overview PageAfter successfully logging into the WebUI, the Overview dashboard is displayed which provides a graphical summary of activity for all the nodes currently communicating with InCenter. An example is shown below.
If no nodes have been added previously, the first step a new administrator will probably want to take is to add one or more InCenter. Doing this is described in Section 3.1.1, Adding NetWall Nodes with the WebUI
None of the changes that are made using the WebUI, either to the InCenter or to nodes, are made permanent until they are committed. If any pending uncommitted changes exist, this is indicated by an orange disk appearing over the changes icon in the top right of the display with a number indicating the number of pending changes.
The example below shows the changes icon with single change is waiting for activation by the administrator.
By pressing the changes icon, the Changes display will open with a list of pending changes. This can also be opened by selected the Changes option from the System menu in the navigation pane.
An example of the Changes display is shown below, with a single pending change which is the addition of a new standalone node called my-node1.
The administrator now has one of the following choices:
Press the Commit Changes button to commit all changes. It should be noted that a commit operation is all or nothing. A selective commit is not possible.
Press the Reject all button to reject all the changes. This will discard any pending changes made since the last commit operation.
Select a single change to see its details and optionally reject just that change.
Also note that filters can be applied to the pending list to show specific types of changes.
If the administrator chooses to commit changes, a final dialog appears for confirmation and provides the opportunity to enter a comment into the history for the commit.
Finally, the WebUI will display a message indicating completion of activation.
This section describes how to set up a NetWall node for monitoring by InCenter. Monitoring means that the node will send log event messages to InCenter so that its activity can be analyzed and presented graphically in the InCenter WebUI.
For monitoring to function, the following two steps are required:
The node must be added to InCenter. Doing this is described in Section 3.1.1, Adding NetWall Nodes with the WebUI.
The NetWall node must be set up to send log messages back to InCenter. Doing this is described in Section 3.1.2, Configuring a Log Receiver in NetWall Nodes.
To make log message sending secure, a VPN tunnel should be set up between the node and InCenter. Doing this is described in Section 3.1.3, Configuring a VPN Tunnel in NetWall Nodes.
Any NetWall node with cOS Core software version 13.00.00 or later installed can be monitored using InCenter.
To add a NetWall node to InCenter for monitoring, select the Nodes option from the Manage section in the navigation pane, as shown below.
Press the Add button and select Node.
This starts the new node wizard which will go through the following steps:
Select the NetWall option and specify a logical name for the node with an optional comment.
|Important: The InCenter name must match the firewall name|
The node name specified in InCenter must match the local node name on the firewall itself. In addition, the firewall name should not be duplicated within InCenter. Therefore, the name may need to be changed locally to a new value in cOS Core before performing the addition in InCenter.
In the last step, a summary is displayed to confirm the details of the addition.
Pressing the Done button will now close the wizard and the added node will appear in the node list.
This change to InCenter now needs to be activated and doing this is described in Section 2.2, Activating InCenter Changes.
For a NetWall node to send log messages to InCenter, a log receiver object needs to be locally configured on the node. Doing this using the node's local WebUI or CLI is described below.
Configuring a Log Receiver with the WebUITo configure a Syslog log receiver in the node's WebUI, open the WebUI in a browser and go to: System > Device > Log Receivers. Then press the Add button and select the option Syslog Receiver.
The dialog for this new object can then be filled in, as shown in the example below.
Note that the IP address specified is the same IP address that is used for SSH management access for InCenter.
The option to make log messages InCenter compatible must also be enabled and this is found in the Advanced tab. Note that this setting can only be found in NetWall nodes running the software version 12.00.16 or later.
Configuring a Log Receiver with the CLIThe node CLI could be used instead to configure the log receiver. The following is an example of a command to do this where the destination IP for log messages is 203.0.113.10:
Device:/> add LogReceiver LogReceiverSyslog my-syslog-receiver IPAddress=203.0.113.10 InCenterCompatibility=Yes
When using the InCenter Cloud service, Syslog messages must be sent from firewalls to the cloud through a VPN tunnel and this tunnel must be locally defined in the node's configuration using a LAN to LAN VPN object. Doing this with the node's WebUI or CLI is described next.
Note that where multiple firewalls are sending log messages to the same InCenter Cloud instance, either each firewall can have its own tunnel, or multiple firewalls can route log messages via a single edge firewall through a single VPN tunnel.
Configuring a VPN Tunnel with the WebUIBefore configuring the VPN tunnel itself, a Pre-shared Key object must first be created that contains the pre-shared key value for the tunnel. To configure this, go to Objects > Key Ring, press the Add button and select the Pre-Shared Key option.
The dialog for the pre-shared key can then be filled in, as shown in the example below. The name can be any suitable text but the key must set to the type Hexadecimal key and the key value copied from the cloud details page and pasted into the Passphrase field. The size should be left at the default value of 512.
To configure a VPN tunnel in the node's WebUI, open the WebUI in a browser and go to: Network > Interfaces and VPN > IPsec. Then press the Add button and select the option LAN to LAN VPN.
The first part of this dialog for this new tunnel object can then be filled in, as shown in the example below.
The following values must be entered:
Remote Endpoint - This is the IP address of the remote tunnel endpoint which is provided on a customer's web access information page for the InCenter cloud. An IP address can be entered directly. However, if an FQDN is used then an FQDN Address object must be created first and then that object is used in this field.
Local Network - This can be any local IP address. Using the IP address object for the local Ethernet interface is recommended, as shown in the example screenshot above.
Remote Network - This is the IP address of the log receiver which is also provided on the web access information page. It is the same IP address that is specified for the Syslog receiver object.
Add route statically - This option must be enabled (by default, it is) so that Syslog traffic is routed through the tunnel.
The second part of the dialog specifies the authentication used for the tunnel. The method should be set to Pre-shared Key and the value of the key should be set to the pre-shared key object created previously.
Activate All ChangesAll the changes made to the cOS Core configuration should now be activated and committed by selecting the Save and Activate option from the toolbar.
Configuring a VPN Tunnel with the CLIAlternatively, the following CLI commands could be used instead. First, to configure the pre-shared key:
Device:/> add PSK my-psk Type=HEX PSKHex=<paste key here>
Next, to configure the tunnel:
Device:/> add Interface LANtoLANVPN my_incenter_tunnel LocalNetwork=G1_ip RemoteNetwork=203.0.113.5 PSK=my_psk
Configuring a Lan to Lan VPN object is described further in the separate cOS Core Administration Guide.
For each node that sends logs to InCenter, a number of dashboards are available in the WebUI which provide both details and a summary of node activity. These dashboards provide information in both a graphical and numerical way.
nodes should first be correctly configured to send log messages to InCenter. The node configuration steps are described in Section 3.1, Setting Up Monitoring. In addition, a node should also have been added to InCenter and doing this is described in Section 3.1.1, Adding NetWall Nodes with the WebUI. It is not necessary for a node to be under full centralized control by InCenter for monitoring to function.
The No-Logs MessageWhen trying to display dashboards for the first time, the message shown below might appear to indicate that no log messages are available for dashboard display.
The above message appears for one of the following reasons:
InCenter aggregates log messages every five minutes and so the first log messages received may not have been aggregated yet. Waiting a few minutes before refreshing the dashboard should resolve this issue.
InCenter has not received any logs from any nodes. The actions given in the no-logs message should be followed to troubleshoot this problem.
Each dashboard provides numeric and graphical summaries of the historical activity for the nodes that have been added to InCenter. Every dashboard has common controls for filtering the information displayed. This filtering can be by:
A particular node can be selected from a drop-down menu.
Multiple nodes can be selected in this way to view the aggregated events from those nodes. The Clear All Filters button can be used to clear all the dashboard filters and return to the default settings.
The most recent period of time can be selected from a drop-down list. This period can range from the last 5 minutes to the last 30 days. Note, however, that the default time of keeping log messages is 3 days and only aggregated data is kept for up to 30 days.
The refresh interval determines how often the dashboard will be automatically refreshed by InCenter. This can be switched off or set at different refresh intervals up to a maximum of one hour.
The administrator has a choice of viewing dashboards in a view mode of Fast or Rich. The Fast option makes use of aggregated log message data. The slower Rich option makes use of the raw log message data but also allows drill-down into that data.
The following should be noted about using these options:
Since the Fast mode relies on aggregated data and because data aggregation by InCenter takes time to complete, using this mode with a short time window of five minutes or less may result in the dashboard display being empty and not showing any node activity.
Log message data is kept for a maximum of 3 days. If the Rich option is selected in conjunction with a time period greater than 3 days, only data from the first 3 days will be displayed. The period beyond the three days will be empty with no indication of activity.
Alternatively, it is possible to build complex queries using the query DSL search language by clicking the Edit Query DSL option.
Note that this filter type is not removed if the Remove All Filters button is pressed. Instead, the delete "cross" button on the filter must be pressed to remove it.
When the InCenter interface is first opened, the default Overview dashboard is presented. This is an overall summary of recent activity for all monitored firewalls. This summary can be displayed at any later time by selecting the Overview option.
Below is an example of the information presented by the first part of the summary.
The second part of the summary provides further graphical represenations of the overall node activity plus a tabular summary of the 10 most active active nodes in terms of data volumes.
The Network Allowed dashboards present an overview of traffic sources that have been allowed by the IP policies of monitored firewalls. An example of the initial dashboard display is shown below.
The various tabs in this dashboard present the following information:
This summarizes the allowed connections that have been processed by application control.
Network & Policies
This presents the source IP addresses that were allowed.
This summarizes the types of URLs that were allowed by web content filtering.
This is a list of the log messages received.
The Network Denied dashboards present the sources of traffic that has not been allowed by IP policies. It can be viewed as the opposite of the Networks Allowed dashboards. The tabs also present the denied networks by type, corresponding to the same tabs in the Network Allowed dashboard.
The Threats Unhandled dashboards are similar to the Threats Denied dashboards but provide an overview of threats that were detected in the "high risk" or "very high risk" categories but which were not blocked.
It may be often desirable to introduce security policies which first audit threats instead of blocking them straight away. This dashboard can give the administrator a way to gauge the effect of changing policies from auditing to blocking.
The Threats Denied dashboards present an overview of threats that have been blocked by monitored firewalls. An example is shown below where a time range of 24 hours has been selected.
The following tabs allow a further breakdown of the denied data:
This summarizes connections dropped by anti-virus scanning.
This summarizes connections dropped by botnet protection.
This summarizes connections dropped by DoS (denial of service protection).
This summarizes connections dropped by the intrusion detection prevention (IDP) subsystem.
This summarizes connections dropped by scanner protection.
The VPN dashboards present a summary of activity related to IPsec, L2TP and PPTP tunnels. Selecting one of the protocol specific tabs provides more detailed information about each protocol.
Note that SSL VPN traffic monitoring is covered by Section 3.2.8, OneConnect.
The Communication dashboard presents a summary of the traffic that is passing through nodes between external hosts and devices. An example of the first part of the communication summary page is shown below.
The second part of the communication summary page provides a tabular summary of the IP rule set entries that are triggering within nodes in order to allow traffic. Columns within this table provide detailed information on how many connections are being allowed for each listed rule set entry and how much traffic is flowing.
The OneConnect dashboard presents the activity of users who are connecting to a NetWall node over SSL VPN using the OneConnect client. Below is an example of the first part of the summary for OneConnect.
The second part of the summary page presents the top users in terms of connections, failed connections, traffic and session time.
The Health display for each firewall summarizes the overall health of the node by displaying the recent levels for CPU load, memory usage, data volume and concurrent connections.
The health display is different from dashboards in that the source data is node generated telemetry data that is always sent every 5 minutes, regardless of what configuration objects exist in the firewall.
To display the health of any firewall, select the node in the node list and then press the Health button.
The health display will open up. The screenshots below show examples of the graphs displayed.
The health display uses machine learning software to track the values of the health telemetry and indicate any anomalies with a red line on the graphs and add these to an anomaly list at the bottom of the page.
InCenter provides the Clavister CyberSecurity Score option with the monitoring feature of NetWall nodes. This option generates a set of "score" displays which are easily understood, snapshot summaries of the current security status for individual or groups of NetWall nodes, or an overall summary for all monitored nodes.
Scores can be displayed by selecting one of the menu options under the CyberSecurity Score heading in the navigation pane of the InCenter WebUI.
If InCenter has not yet received sufficient data, it will display the following message when a score display is requested.
The above message may also be displayed when the score display is requested for a particular node that has insufficient data but there is sufficient data for other nodes.Overview option will provide a summary for all monitored NetWall nodes. Below is an example of a typical summary display for all nodes.
By using the drop-down box on the upper-right, this display can be recalculated for individual nodes or node groups.
On the left side of this display is an alphabetical score between A (the highest level) and F (the lowest). This provides a quick indicator of overall security status.
On the right side is a threat indicator that takes a percentage value between 0 (the lowest threat level) and 100 (the highest threat level). Unlike the other measures which are averages, the threat indicator value is the highest value found among all the nodes or among those that are currently selected.
In between are colored bar meters that provide a score level between A and F for the following individual security categories:
This score highlights problems due to node configurations. For example, features are disabled leaving the network open for potential attacks. It will also highlight if nodes are not using the latest software version.
This score highlights the health of nodes in terms of performance and connectivity.
This highlights threats from internal hosts. If threats are seen from specific nodes then it could be wise to review how these nodes are allowed to communicate on the network.
This highlights identity and authentication issues that may impact the availability. It will also highlight high ratios of non-authenticated traffic, which make it harder to track down the original source of threats.
This score highlights the level of protection and security on VPN connections
This score highlights the level of protection and security status of nodes.
Under the score display is a list of Top 3 Suggested Improvements which indicates suggested ways that the overall score could be improved.Details menu option presents a more detailed view of the score for each node.
The colored bar on the right side of each indicator gives a measurement for the contribution of that factor to the overall score for that node. A red bar shows that the indicator made a significantly negative contribution and green shows a marginally negative contribution. The indicators are initially ordered with the most negative contributors first. The recommendation is for the administrator to address the most negative indicator first in order to improve the overall score for that node.date picker. The date picker is a drop-down box above all score displays.
Clicking the picker presents a day by day calendar which shows historial summary score values. By clicking on a day in the calendar, the complete score details for that day will be displayed.
The Reporting section of the InCenter system allows dashboards to be turned into PDF reports that can be automatically sent to a list of email recipients. The creation of reports can be done at a chosen point in time, either at the beginning of the day, week or month.
To create a new report, select the Configure option from the Reporting menu in the navigation pane. (The Preview option duplicates the information from the dashboard displays.)
Next, press the Add button to define a new report.
The new report dialog will be displayed. The first information to enter is a name for the report along with selecting the firewalls which will contribute the data for the report. The firewalls must have been previously added to InCenter for them to appear in the drop down list. The list also includes any groups that have been previously defined.
In the next part of the dialog, select the dashboards that will be included in this report.
Define the frequency that the report will be generated. This can be either at the beginning of each day or each week or each month.
Next, the recipient(s) of the report can be entered as a comma separated list of email addresses along with text for the subject line and text for the email body (the report PDF will be an attachment to emails).
After clicking the Save button at the bottom of the dialog, this report will now appear as one line in the report list and can be edited or deleted at any time.
InCenter provides the ability for the administrator to be made aware when certain events occur, including the option to receive alarms for specified events via email. In describing the alerting subsystem. the following terms will be used:
A ticket type corresponds to a particular log event message that can be generated by a node. All ticket types are predefined in InCenter. Ticket types can be set to a state of either being enabled or disabled. When they are disabled, InCenter will ignore them if they occur. By default, all types are enabled.
This collects together all the occurrences of a given ticket type for a given node. When a ticket is created it is initially in an unacknowledged state and must be explicitly acknowledged by the administrator before it moves to an acknowledged state.
An alarm consists of an email that is sent when selected ticket types occur.
The alerting feature is managed through the Alerting menu options in the navigation pane, which are shown below.
When the Ticket Types option is selected, a list of all available ticket types is presented. An example of the first few lines of this list is shown below.
Each line in the list corresponds to a particular event or ticket type that InCenter will create a ticket for from incoming log messages. The slider on the right allows the administrator to choose if that ticket type should be monitored or not. By default, all ticket types are enabled. The pencil icon on the left indicates an On/Off change that has not yet been activated.
When a monitored event occurs, it is added to the Open Tickets list and the number of unacknowledged tickets in the list is indicated by a number next to the alerts icon in the toolbar.Tickets option in the navigation menu. As shown in the example below, the list displays how many times that ticket type's log event has occurred for a given node in the Events column. The Created column shows when the ticket first occurred for that node and the Updated column shows when it last occurred for the node.
The ticket list can be extensive so filtering is possible by type, severity or node. Below, only the tickets with Medium severity are being selected.
Each open ticket line corresponds to a given ticket type for a given node. Tickets remain in the Open list until they are acknowledged. This is done by first selecting a line in the Open list to open the Ticket Details dialog. An example of this dialog is shown below.
By pressing the Acknowledge button, the entire ticket is moved to the Acknowledged list (accessed through the Acknowledged tab). The acknowledged tickets will persist as an historical record for 30 days before being automatically deleted by InCenter.Events link in the dialog shown above allows the administrator to view the individual received log messages that caused the event count for this ticket type and this node to be incremented. However, not all logs may be saved by InCenter. Some may be discarded when they duplicate previous log events or do not add extra information to them.
The Information link will provide a brief summary description of the ticket type, as shown in the example below.alarm can be created by selecting Alarms from the Alerting menu and then pressing the Add button.
The new alarm dialog is then presented. An example of this is shown below.
In the above dialog, the administrator can select the ticket types for which alarms are to be generated and the email addresses of the recipients. An email is generated whenever any of the selected tickets occurs and sent to all the recipients.
Note that an alarm is only sent the first time a ticket is generated for a given ticket type and node. In other words, only once per ticket type per node. If that ticket is then acknowledged by the administrator, it becomes possible for the same alarm to be sent again if the same ticket types occurs again.
The Devices menu option presents the available data about the types of user devices which are connecting to all the NetWall nodes being monitored by InCenter. This is achieved by cOS Core performing device fingerprinting on the traffic from from devices as they connect.
Note that the term "device" in the context of InCenter refers to client equipment such as smartphones, tablets and laptop computers. It should be contrasted with the firewalls through which they are connecting which are referred to as "nodes" in InCenter.
This display is accessed via the Devices menu option and then choosing the Details option.
The devices that are fingerprinted are only those where the node is acting as a DHCP server to the device (or it is relaying DHCP server traffic to the device). The complete details of how cOS Core fingerprinting functions is discussed further in the Device Intelligence section of the separate cOS Core Administration Guide.
Below is an example of how the detailed device list is displayed.
Note that each line gets an arbitrary logical name from InCenter, which appears in the Name column. For example, device7. However, this name is used only as a unique identification by InCenter and is not used by the device itself or the node.
A textual description of the Type column icon will appear in a tooltip when hovering the cursor over the icon. An example of this is shown below.
The type classification comes from the Fing™ device database, which cOS Core uses to identify a device.
Clavister NetEye is a standalone product that performs high performance virus scanning, which includes SSL inspection. NetEye is available either as a cloud service or running on dedicated local hardware.
InCenter can be used to collect and analyze log messages generated by NetEye but, at this time, only a NetEye cloud instance is capable of sending log messages to an InCenter cloud instance. Both the NetEye cloud instance and associated InCenter cloud instance must be registered to the same MyClavister account.
When NetEye log messages are received by the InCenter server, they are stored in the same way as logs from a Clavister firewall and can be displayed in graphical form using the InCenter WebUI. This display is accessed via the NetEye menu option in the Analyze menu. Below is an example of the WebUI summary display forNetEye.MyClavister account and is described further in the Neteye Setup chapter of the separate InCenter NetEye Cloud Getting Started Guide.
Any number of new InCenter user accounts can be created for administration and/or auditing purposes. Having a number of different users can be useful for logging purposes, where the username responsible for an action is included in that action's log message and history entry.
Authentication MethodsThe following user authentication methods are available:
Authentication with Username/Password Credentials
This default type of authentication involves the user entering credentials consisting of a username and password combination.
User Access LevelsEvery InCenter user has one of the following two values for its AccessLevel property:
The user has full system access and can read or change any part of the configuration. InCenter will not allow the number of this type of user to fall below one.
The user has no ability to change the configuration or affect the operation of InCenter but has read-only access to the complete configuration.
The access level does not have a default value so it must be specified for every user that is added to the system. Users that already existed prior to upgrading to a version with the access level feature will automatically get the Administrator level.
Conforming to the User Password PolicyBy default, the password length must be not less than 8 characters and must contain at least one upper case, one lower case, one numeric plus one non-alphabetic/non-numeric character.
In the case of such multiple login sessions by an administrator user, all sessions will see and update the same configuration set. In other words, the changes made in one session will affect all other concurrent sessions.
In the case of an auditor user, they can see the changes being made by an administrator user but cannot activate or otherwise affect such changes.
Disabling UsersBy default, a user is enabled. However, it is possible to disable a user account. This means that the user remains in the user database but their credentials will not be recognized at login.
To display all current system users names in the WebUI, first press the Admin button at the top right of the WebUI display and select Manage Users.
A list of current users will be presented. To add a new user, press the Add button.
The new user dialog will now be presented and the new user credentials can be entered.
In addition, the access level for the user can be set as either Administrator or Auditor.
When the user details have been entered, press the Save button to add the new user.
Unlike other configuration changes, modifying the user database does not require that the change is activated before it is applied. User database changes are applied immediately.
A node can be assigned membership in a NodeGroup. The group concept provides the ability to apply administrative actions to a group instead of an individual node, where the action will apply to all the nodes within the group
No predefined groups exist in InCenter so they must be defined by the administrator and then assigned to nodes.
The Rules of Using GroupsThe following rules should be noted when using groups:
A single node can only be a member of a single group.
A group can contain other groups.
Individual HA members cannot be group members, instead it is the HAPair object that is added and as a consequence the HA members are indirectly included in the group.
If a group is deleted, its members become children of any parent group. If there is no parent to the original group then the children will have no group membership after deletion.
To define a new Group object, go to Manager > Groups and then press the Add Group button.
Press the Add button to bring up the new group dialog. The upper part of this is shown below. It is possible to specify an existing group which will have this new group is a member.
In the lower part of the dialog, the individual nodes can be added to the group. Other groups or HA pairs can also be added. With the same dialog, it is also possible to add members to the group from existing groups.
The InCenter product makes use of various third party software. A list of all third party software and the associated licenses can be found in a single text file called acknowledgments.txt which is included with each release of the software.
The file can be downloaded by first pressing the About button at the top pane of the display.
This displays the About dialog. The acknowledgements button in the dialog can then be pressed to download the acknowledgements file. This is shown in the example screenshot below.
As can be seen in the above screenshot, the About dialog includes the release notes for the version of InCenter that is running. These notes are also displayed automatically after user login if there has been a version upgrade of InCenter since the last login.