Reporting Overview
CyberEdge reporting provides network administrators with visibility of network, system and event data using an on device reporting engine. The following outlines the setup and configuration of the CyberEdge reporting as well as best practice recommendations. If required, CyberEdge event data can be forwarded to third party reporting applications for long term storage or analysis.
When enabled, the CyberEdge reporting application and event data is accessible at https://reporting.localnetwork.zone/.
Storing Events
The CyberEdge is able to log and store event data to the local database allowing administrators to view, analyze and better manage the network. Event data stored by the CyberEdge includes:
- Network Monitoring: Network events for all network traffic traversing network zones.
- Network Connections: Events tracking the status of the network connections and interfaces of the CyberEdge.
- Access Policy Events: Events generated by Access Policies matches where the "log events" action is enabled.
- Threat Management: Security events generated by the Intrusion Prevention System (IPS).
- IP Bans: IP ban events generated by Access Policies, New Connection Rate limiting and Brute Force Detection.
- IP Restrictions: Events generated by user-initiated IP restrictions via the LiveZone portal.
- Port Forwards and 1:1 NAT: Network events for connections triggered by port forward and 1:1 NAT policies.
- Authentication: User-based authentication events to report on authentication sessions.
- YouTube Analytics: YouTube video events with enriched data via Google API (requires HTTPS inspection).
- Change History: Events created by any configuration change to the CyberEdge.
- Content Scanning: Events generated by Content scanning policies (requires HTTPS inspection).
- SpeakUp: SpeakUp data submitted by a user via the LiveZone portal.
Info
- Event data stored in the reporting event database is not encrypted
- Network Access Controls should be implemented to manage access to the reporting application
- CyberEdge HA (Active/Passive) configurations do not replicate reporting event data between nodes. See log forwarding for HA report recommendations.
- The reporting application is served from a secure container that is segmented from the CyberEdge Management user interface.
Manage Storage
The CyberEdge stores event data in data source tables. Data sources retain up to 8 weeks of event data where possible, except for Authentication and Change History events, which retain up to 52 weeks of data. The system prioritizes the ability to record new events, and will automatically purge old events to free up space if required. If the available database storage becomes low, Network Monitoring data will be dropped as a priority one week at a time, down to a minimum of 4 weeks.
If required, system administrators can manage event database storage. To view your disk utilization or purge event data go to Reporting > Storage and perform the following:
- Identify event tables with large disk utilization. This will typically be the Network Monitoring and/or Access Policy event tables. Event tables are listed in order of total disk space used.
- Select the event table or tables you wish to purge. You can select all tables to remove the oldest week from each event table.
- Select "Remove oldest Week"
- Confirm selection
Data for the selected tables will be dropped immediately. If Access Policy event tables are exceptionally large, you should consider reviewing your Access Policy logging action to minimize unnecessary event creation.
Important info
- Database storage warning emails are sent to the configured alert email address recipient. (See System > General > SMTP Relay configuration)
- If the database reaches critically low storage limits of 2% all events, except for Authentication and Change History events, will no longer be written to the database and will be lost.
- System administrators can drop event data by data source as required with no system impact.
- Event data dropped by the administrator cannot be recovered.
- For CyberEdge H/HR/HR2 Series appliances, event storage capacity is approx 246GB.
- CE Virtual machines will allocate up to 60% of the allocated storage
Data Retention Periods
To achieve meaningful reporting and the longest possible retention periods for event data, it is important to consider what events are chosen to be stored. To reduce the storing of unimportant event data, system administrators can control whether or not logs and events are generated when an Access Policy is matched.
Some examples of Access Policies that can generate extremely large numbers of event data include:
- Blocking of App Stores such as the Apple App Store, Microsoft Store and Google Play. In large networks, this may generate millions of requests per week and provides little reporting value.
- Blocking Google DNS traffic such as
dns.google.com
. Google tries aggressively to make connections to its services over DNS and may generate a large number of events. - Blocking Spotify can generate a large of number of block events due to its application design and constant client application attempts to access its cloud infrastructure.
- Logging allows of
microsoft.com
domains such assharepoint.microsoft.com
andoffice365.com
. - Online ad block policies.
Info
You can review your Access Policy logging configuration within each policy. Go to Security Centre > Access Policy > Edit > Action and view if log event is enabled.
Configure Reporting Application
By default, the reporting application and associated API's are disabled. The administrator can manage how the application is served on the network and implement strict access controls. To enable the reporting application and manage access:
- Go to Reporting > General.
- Set "enable reporting interface" to ON.
- By default, the reporting application is served on port 443. If required, specify a custom port to be used.
- Enter a network or networks that are allowed access the reporting application.
- Enter network zones that are allowed to access the reporting application. When zones are used, all networks within the zone will be granted access.
- If required, specify a custom domain to serve the application.
- If a custom domain is used, select the related SSL certificate to be used. (To generate or upload a certificate, go to System > Certificates.)
- Specify a Single-Sign-On service provider to be used when authenticating to the application server. Leave blank to use usernames and passwords for authentication.
- Click "Save" and apply the change.
Info
- By default, the reporting application is accessible at https://reporting.localnetork.zone/
- The reporting application is always accessible from networks within the management zone
- If individual networks or network zones are not provided, access to the reporting application will be restricted to the management zone only
- User authentication is always enforced. To improve security and provide a better user experience, it is recommended to configure a SSO provider and enable MFA. Information on how to setup a SSO authentication provider can be found here.
Report Scheduling
The CyberEdge can be configured to generate and schedule the delivery of pre-defined reports. Reports are generated using data stored in the local events database. To schedule reports:
- Go to Reporting > Scheduled Reports.
- Click "Add".
- Add a report name and description.
- Select from the list of pre-defined reports: Network Administration, General Usage, Student Welfare, Leadership Overview.
- Set the reporting frequency of the report: Daily, Weekly, Monthly, Quarterly.
- Set a time for the report to be sent. Note, this does not change the query time range for the report and relates only to the time the report is sent.
- Specify one or more email recipients to receive the report.
- If you require report data to be limited to specify groups of users, specify one or more user groups.
- Click "Save" and apply changes.
You can add and remove as many scheduled reports as required.
Info
- Weekly, Monthly and Quarterly reports can be large in size.
- To ensure reports are emailed successfully, please ensure SMTP relay is correctly configured. To view the SMTP configuration go to System > General > SMTP and click "Test".