FAQ

Is Cyfin Receiving Syslog from Your Firewall or Proxy? A Troubleshooting Guide

If you’ve configured a firewall, proxy, or gateway — a SonicWall, Palo Alto, Checkpoint, WatchGuard, Cisco Firepower, Zscaler, or similar device — to send syslog to Cyfin, but your reports are empty, a device isn’t showing up, or the traffic you expect isn’t appearing, this guide will help you pin down where the problem is.

Almost every “Cyfin isn’t showing my firewall data” issue comes down to one question:

Is the syslog data actually reaching Cyfin?

That single question splits the problem into two very different situations, each with a different fix:

The data isn’t arriving. The stream isn’t reaching Cyfin at all. This is almost always something in how the sending device is configured to forward syslog, or something on the network path between it and Cyfin. We’ll show you how to confirm this and what to check.
The data is arriving, but Cyfin isn’t turning it into reports. The stream is reaching Cyfin, but Cyfin either doesn’t have a parser for that device’s log format, or the format isn’t quite what the parser expects. This is the case where we can help you directly — often quickly.

Work through the guide in order. The first job is simply to find out which of those two situations you’re in.

What Cyfin can parse

Cyfin reads log data from many firewall, proxy, and gateway devices, but it reads a specific set of log formats. When a device sends syslog in a format Cyfin recognizes, Cyfin parses it into users, sites, and categories automatically. When it sends a format Cyfin doesn’t yet recognize, the data can arrive perfectly and still produce nothing — because Cyfin doesn’t know how to read it.

Devices and formats Cyfin parses out of the box:

Palo Alto Network

Check Point

Cisco Firewall

Cisco Firepower

FortiGate

SonicWall

WatchGuard

Zscaler

If your device isn’t on that list, that doesn’t necessarily mean Cyfin can’t read it — it means we may need to add or adjust a parser for your specific format. See “The data is arriving, but nothing shows up” below; that’s a fast turnaround when we have a sample of your log.

Step 1: Confirm whether Cyfin is receiving the syslog

You can check this yourself, directly in Cyfin — no command-line or server access required. This works the same whether Cyfin is running in a VM on your own network or hosted in the cloud, so you don’t need to touch the underlying machine either way.

In Cyfin, go to:

System Status → Syslog → Syslog Status

This screen shows statistics on the syslog Cyfin is receiving, along with a live sampling of the incoming data. It’s the definitive, self-service answer to “is anything arriving?”:

You see stats climbing and sample data on the screen → syslog is reaching Cyfin. The problem, if any, is on the parsing side. Skip to “The data is arriving, but nothing shows up.” (Keep this screen open — the sample it shows is exactly what support will need, so it’s worth capturing now.)
The screen shows no activity — no stats, no sample — while the device should be sending → the data is not reaching Cyfin. Continue to Step 2.

Note for Cloud Cyfin customers: your instance is administered by Wavecrest, but you still confirm receipt yourself through this same Syslog Status screen. If the screen shows nothing and the send side checks out, Wavecrest can additionally verify at the network level on the hosted server — see Step 2.

Step 2: The data isn’t arriving — get the stream flowing

If nothing is reaching the server, the syslog isn’t leaving the sending device, isn’t addressed correctly, or is being stopped on the network in between. The exact steps to configure forwarding live in your device’s own admin interface — and because every vendor’s interface is different, those specific screens are outside what we can document for you. But the requirements the device has to meet are the same for every vendor, and you can verify each one:

1. Destination address. The device must be sending to the IP address (or hostname) of the Cyfin server. Confirm it’s pointed at the right host — not an old address, not a load balancer or gateway that drops it.

2. Port and protocol. The device must send on the port and protocol Cyfin is listening on (typically UDP/514 — but confirm against the value above). A mismatch here is one of the most common causes: the device sends on UDP/514, Cyfin listens on something else, and nothing lands.

3. A clear network path. Nothing between the device and Cyfin can be dropping the traffic. The usual culprits:

A firewall rule (often on the sending device itself, or a firewall in between) blocking outbound/inbound syslog on that port.
NAT or routing that prevents the packets from reaching the server.
The device and server being on segments that can’t reach each other.

How to localize the break: you own both ends you can actually see — the Syslog Status screen tells you nothing is arriving at Cyfin, and your sending device’s own logs or status page tell you whether it’s actually transmitting. If the device shows it’s sending but Cyfin’s Syslog Status stays empty, the packets are being lost on the network in between (firewall, NAT, or routing) — that’s the path to work through. If the device isn’t showing outbound syslog activity at all, the forwarding config on the device isn’t active yet, and that’s where to focus. For Cloud Cyfin, if you’ve confirmed the device is sending but nothing arrives, Wavecrest can capture at the network level on the hosted server to confirm definitively whether packets are reaching it.

We know that even though the sending device’s configuration is on your side of the fence, you’re looking to us to help you get this working — and we will. If you’ve verified the destination, port, and path and syslog still isn’t arriving, contact support (below) and we’ll help you work through it. What we can’t do is write the click-by-click steps for your specific vendor’s admin UI; for that, your device vendor’s syslog-forwarding documentation is the authority.means the network/firewall is eating them; not leaving the device at all means the forwarding config on the device isn’t active.

Step 3: The data is arriving, but nothing shows up

If the Syslog Status screen shows data arriving but Cyfin still produces no reports — or the data looks wrong, miscategorized, or partial — the issue is on the parsing side: Cyfin is receiving the stream but doesn’t have a parser that matches your device’s exact log format.

This is the case we can usually turn around quickly — as long as we can get a sample of your actual log. With a real sample in hand, adding or adjusting a parser for your format is fast, straightforward work. Without one, we’re guessing at a format we can’t see.

To get this resolved quickly, contact support and include:

The device sending the logs — make and model (e.g. “SonicWall TZ470”, “Palo Alto PA-440”).
A sample of the raw syslog — a handful of representative lines exactly as they arrive. The easiest place to get this is the System Status → Syslog → Syslog Status screen, which shows a live sampling of the incoming data; copy or screenshot those lines so we see the real bytes Cyfin is receiving, not a reformatted copy.
What you expected to see in Cyfin versus what you’re actually getting (nothing at all, wrong users, wrong categories, etc.).

That sample is the one thing that turns “my device doesn’t work with Cyfin” into “here’s the format, we’ll add the parser.” The faster we have it, the faster this closes.device doesn’t work with Cyfin” into “here’s the format, we’ll add the parser.” The faster we have it, the faster this closes.

Quick reference: which situation am I in?

What the Syslog Status screen shows	Where the problem is	What to do
No activity — no stats, no sample	Sending device config or network path	Step 2 — verify destination, port/protocol, and path; contact support if still stuck
Data arriving, but no reports in Cyfin	Parser / log format	Step 3 — send support a raw log sample
Data arriving, but reports look wrong	Parser needs adjustment	Step 3 — send support a raw log sample + what’s wrong
Haven’t checked yet	Unknown — check first	Step 1 — open System Status → Syslog → Syslog Status

Contact

For help confirming whether Cyfin is receiving your syslog, or to have us add or adjust a parser for your device, contact Wavecrest support:

[VERIFY — insert the canonical support contact (support email + technical support phone/extension). Per current routing: technical/syslog/parser issues go to SUPPORT, not sales. Sales — sales@wavecrest.net, 321-953-5351 — handles only licensing, renewals, and purchasing.]

When you contact us about syslog that’s arriving but not parsing, include the device make/model and a raw log sample — that’s what lets us turn it around fast.

Cyfin / Cyblock — Single-Box VMware Sizing Reference

VM on-prem deployment: syslog reception, ingestion, and report generation on one VM in the customer’s own environment. Cyblock adds live inline proxy traffic. Metric server sizing included separately. Result quality is identical to a split-tier deployment; the numbers below simply account for running these functions together.

All numbers are minimum production baselines (row 1 of each table) with headroom tiers above them. Scale up with log volume, report concurrency, and user count.

What to size for: concurrent workloads

In a VM on-prem deployment these functions run alongside each other, so provision for peak concurrency rather than any one job in isolation:

Syslog reception — light CPU, network-bound; give it burst headroom so it never drops.
Ingestion — CPU-active (parse + URL categorization lookups), heap allocation, disk writes.
Report generation — CPU-active and heap-active; a large report can use every core and a lot of heap.
Metric server — a distinct ES-backed process; include its resources when co-located.

The main case to plan for is a large report running during active ingestion — size so both run comfortably at the same time.

Cyfin (syslog + ingest + report)

Tier	vCPU	RAM (heap ≈ half)	Notes
Minimum production	4	8 GB (4 GB heap)	Light volume, few configs
Medium	8	16 GB (8 GB heap)	Comfortable report-while-ingest concurrency
Heavy	8–16	32 GB (12–16 GB heap)	Cores drive reporting parallelism

Heap past ~12–16 GB gives diminishing returns and longer GC pauses. Allocation rate, not heap size, is usually the practical ceiling — size cores and heap together rather than heap alone.

Cyblock

Everything above, plus the proxy serves user browsing in real time, so keep cores available for it. Size the proxy piece by concurrent users / request rate on top of the ingest+report sizing, and give the proxy guaranteed CPU.

Tier	vCPU	RAM	Notes
Minimum production	4–6	12 GB	Proxy + modest reporting
Medium	8	16–24 GB	Cores reserved for proxy
Heavy	12–16	32 GB+	Proxy connection state + category cache + report heap all resident

Metric server (out-of-the-box)

Distinct process powering real-time metrics/dashboards. Sizing scales with metric retention and dashboard/query concurrency. Heap guidance: keep heap ≤ 50% of RAM and under ~31 GB; the remaining RAM benefits disk caching.

Tier	vCPU	RAM (heap ≤ half)	Notes
Minimum production	4	8 GB (4 GB heap)	SSD-backed; rest of RAM aids caching
Medium	8	16 GB (8 GB heap)	Higher retention / more concurrent dashboards
Heavy	8–16	32 GB (≤16 GB heap)	Large metric volume; keep heap ~31 GB or under

When co-located, include the metric server’s resources in the box total, or give it its own CPU reservation.

VMware-specific guidance

Match vCPU to physical cores and avoid host overcommit for these VMs. CPU ready / co-stop time is invisible inside the guest and slows reporting. Prefer fewer, well-scheduled vCPUs over a large oversized count.
Set a memory reservation at (or near) full VM RAM so the JVM heap (product or metric server) is never ballooned or swapped — that keeps GC behavior predictable.
Cyblock: set a CPU reservation/shares so the live proxy always has cycles regardless of concurrent reporting.
Fast datastore — SSD-backed with PVSCSI. Report scans and metric-server indexing are disk-sensitive, so storage throughput is often the first thing to raise.

Note

To tighten these into a single recommendation, plug in the deployment’s log volume (GB/day or events/sec) and user count.

Renewing or Updating Your License (Cyfin & CyBlock)

Applies to: Cyfin and CyBlock · Renewing a license or extending a trial.

Your Cyfin or CyBlock license is renewed by contacting Wavecrest sales, who provide a new activation key. You then enter that key on the Update License Information screen to apply it. The process and screen are the same in both products.

Who needs to contact sales

Existing customers renewing their license — sales issues a new activation key once your renewal is arranged.
Trial / evaluation users — an evaluation includes a 14-day trial license. To extend the trial beyond 14 days, contact sales for an extended trial key.

In all cases, the activation key comes from sales; it isn’t self-generated in the product.

Where to find your license screen

Go to Settings → License → Update License Information.
The License Details screen shows your Organization Name, Server Alias Name, Serial Number, Activation Key, and the Key Status — the latter shows how many days remain and the expiration date (for example, “240 Day(s), until Apr 29, 2027”). Check Key Status any time to see when your license expires.

How to apply a new activation key

Contact Wavecrest sales to arrange your renewal (or trial extension). Sales provides a new activation key.
In the product, go to Settings → License → Update License Information.
Enter the new key in the Activation Key field (replacing the existing one).
Click Submit. The Key Status updates to reflect the new expiration date.

Contact

To renew, extend a trial, or ask any question about your license, contact Wavecrest sales:

Phone: 321-953-5351
Email: sales@wavecrest.net

There’s also a Contact Sales link on the License Details screen.

How to Change the Time Zone in Cyfin

Applies to: Cyfin · Setting the time zone for a data source.

Cyfin sets the time zone per data source, not as a single system-wide setting. There’s no global “product time zone” toggle — you set the time zone inside each data source’s configuration. This is by design: a large organization may pull logs from offices in different regions, and each data source can be interpreted in its own local time so the timestamps in reports are correct for where the activity actually happened.

You change it in the Data Source Setup wizard.

Steps

Go to Data Management → Setup. This opens the Data Source Setup wizard.
Select the data source you want to configure. Its settings screen (Data Source Setup) is displayed.
Locate the Timezone field and select the correct time zone for that data source from the drop-down (for example, America/Los Angeles).
Check the Raw Date and Parsed Date shown on the screen to confirm the offset is being applied as expected — the Parsed Date reflects the time zone you selected.
Click Next, then name the configuration and complete the wizard to save.

Notes

Set it per source. If you have multiple data sources from different regions, repeat these steps for each one and set each to its own local time zone.
Verify with Raw vs. Parsed Date. The Raw Date is the timestamp as it appears in the log; the Parsed Date is how Cyfin will interpret it after applying the selected time zone. Use the two together to confirm you’ve picked the right zone before finishing.

Cyfin — Why Are User IDs Missing From My Reports?

Applies to: Cyfin · When reports show no usernames (blank or IP addresses instead of people).

Cyfin reports on whatever is contained in the log or syslog data it ingests from your firewall or proxy. User IDs are what let Cyfin attribute web activity to specific people. If your reports show activity by IP address or blank instead of by username, the User ID is missing from the data Cyfin is receiving — and it’s almost always one of the two causes below.

(This is different from activity that appears under Ungrouped IDs — that means IDs are being captured but haven’t been organized into your Groups and IDs tree. See the Terms Glossary for Ungrouped IDs. This article is about IDs not being captured at all.)

Cause 1 — Your firewall or proxy isn’t capturing the User ID

This is the most common cause, and the key fact to understand:

The User ID is not a default field in any firewall or proxy log. A firewall or proxy only records who made a request if authentication is enabled on that device. By default, most devices log the connection (IP, URL, time, bytes) but not the authenticated username. If authentication isn’t turned on, there is simply no User ID in the log for Cyfin to report on — this is a configuration on the device, not something Cyfin can add after the fact.

The fix: enable user authentication on the firewall or proxy that generates your logs, so the authenticated User ID is written into the log/syslog. Once the device is capturing usernames, they flow into Cyfin and appear in reports.

How to do it depends on your device. Every firewall and proxy vendor has its own process and terminology for this — it may be called user authentication, user identification, User-ID, identity awareness, or similar. Consult your device’s documentation (or its vendor support) for how to enable authenticated user logging. Common examples include Palo Alto (User-ID), SonicWall, Fortinet (FSSO), and Check Point (Identity Awareness), among others.

How to confirm it’s a device issue: look at the raw log or syslog Cyfin is ingesting. If there’s no populated username field in the records themselves, the gap is on the device side — enabling authentication there is the fix.

Cause 2 — Authentication is enabled and IDs are in the log, but not in reports

If your firewall/proxy authentication is already on and you can see usernames in the raw log/syslog, but those usernames still aren’t showing up in Cyfin reports, the issue is on the parsing side: the log/syslog format or fields may have changed, so Cyfin’s parser no longer maps the User ID field correctly.

The fix: contact Wavecrest Technical Support (support@wavecrest.net). Let them know authentication is enabled and usernames are present in the raw log but not appearing in reports. The log fields may have changed and Cyfin’s parser / data configuration may need to be updated to read the User ID from the current log format.

Quick summary

Reports show IPs/blank, and the raw log has no username → enable authentication on your firewall/proxy (Cause 1). The User ID is never a default log field.
Reports show IPs/blank, but the raw log does have usernames → contact Wavecrest Support; the parser may need updating (Cause 2).
Reports show usernames but they’re all under Ungrouped IDs → that’s a grouping issue, not a capture issue; build or sync your Groups and IDs tree (see the Terms Glossary).

Cyfin & CyBlock Terms Glossary — Key Terms Explained

Applies to: Cyfin and CyBlock · Plain-language definitions of the terms used across the products and their reports.

This glossary defines the terms customers most often ask about — the reporting metrics, the categorization concepts, and the product features that shape what you see. Unless noted, a term applies to both Cyfin and CyBlock. For the full report list, see the Report Glossary; for the full category list, see the Category Glossary.

Reporting metrics

Session — A period of continuous user activity with a single application/site, reconstructed from the log. Sessions rebuild scattered proxy/firewall connection records into readable browsing events and filter out non-human background traffic (OS updates, telemetry, ad trackers), so a report reflects what a person actually did rather than raw log volume. Session count is the primary metric in high-level reports.

Session Duration — The elapsed time from the first to the last record within a session, shown as HH:MM:SS — meaningful active time, not raw connection time. Available only in the session reports. It replaces the retired Time Online metric.

Session Thresholds — The conditions activity must meet to be recorded as a session (for example, a minimum duration, a minimum number of hits, an inactivity timeout, and a maximum duration). These are Wavecrest-managed settings and should not be changed without Wavecrest’s assistance — please contact Technical Support before adjusting them.

Sessions % — A given application/site’s or category’s share of all sessions, shown as a number and a classification-colored bar.

Session Duration % — A given application/site’s or category’s share of total reporting-period time. A site with few sessions can still show a high duration % if those sessions were long.

Hit — A single log record. One page load generates many hits (images, scripts, stylesheets, and background requests). Hits are the raw material sessions are built from and appear at the deepest drill-down level, not as a headline metric. In the hit-based reports (everything outside the session reports), activity is measured in hits and bytes.

Bytes — The volume of data transferred, shown in KB or MB.

Denied Request — A request blocked by your proxy or firewall before it reached its destination. A non-zero count means access to blocked content was attempted during the period or session.

What happened to Visits and Time Online?

Both metrics have been retired. Visits have been upgraded to Sessions, which capture a user’s continuous engagement with a site rather than a single-interaction count — a clearer, more accurate picture in today’s dynamic web. Time Online has been replaced by Session Duration, which is available in the session reports. The hit-based reports now measure activity by Hits and Bytes and no longer show Visits or Time Online. This reflects how the web changed, not a correction of past reporting.

Categorization terms

Category — The content category assigned to a website (e.g., Video Streaming, Gambling, News), drawn from the shared Wavecrest URL List. See the Category Glossary for the full list and definitions.

Classification — A label — Acceptable, Unacceptable, or Neutral — that a customer assigns to each category to reflect their company policy. It appears in reports (color-coded: green / orange / gray) to give the report consumer a policy-based read on activity. Classification affects reporting only; it does not by itself block anything.

Custom Category — A category you create yourself (beyond the 70+ standard categories) and populate with URLs of your choosing — for example, to track intranet sites or to group a set of sites for filtering. Custom category and URL changes override future Wavecrest URL List downloads.

OtherWise — An optional program Cyfin and CyBlock customers can opt into to help improve categorization. When enabled, domains that are missing a category or tag are forwarded to Wavecrest’s cloud list server for review and analysis. Only the domain that needs review is sent — no other information — and the result is better list quality for everyone.

Acceptable Use Policy (AUP) — Your organization’s own policy defining acceptable web use. Cyfin and CyBlock help you monitor and enforce your AUP through their customization features (categories, classifications, and — in CyBlock — filtering).

Users and groups

User ID — The network login identifier used to attribute activity to an individual across all reports (e.g., firstname.lastname). Cyfin reads IDs from the log; CyBlock obtains an ID via NTLM when creating a proxy connection.

Groups and IDs — The tree of users and groups the product uses to organize activity. You can build it manually or sync it from Active Directory (importing your existing group and ID structure). Reporting and policies can then be organized by group.

Ungrouped IDs — Where an ID lands when it isn’t matched to an entry in your Groups and IDs tree. When Cyfin reads an ID from the log — or CyBlock receives one via NTLM — that ID is checked against the tree; if it doesn’t match a defined ID, it’s placed in Ungrouped IDs. If you never build a tree or sync from Active Directory, all IDs go into Ungrouped IDs by default. (If you’re running a report and can’t find the IDs you expect, this is often why — they’re sitting in Ungrouped IDs because the tree hasn’t been built or synced.)

Product features

Coaching (CyBlock only) — A filtering option that, when enabled, adds an override link to the block message shown when an employee reaches a blocked site. The employee can choose to bypass the block and continue to the site — and that action is logged, so the organization can later verify whether the visit was legitimate. Customers use coaching as a safety valve in case a valid site is blocked and a user genuinely needs access.

Ingestion — The process of loading raw proxy/firewall log data into the product for a given user and period. Reporting begins after ingestion completes. By default, known non-human domains (ad trackers, telemetry, OS updates, endpoint security) are excluded during ingestion; this can be disabled if a full traffic record is needed.

Application / Web Site (App/Site) — A recognized web service that groups all its related domains under one friendly name (e.g., fbcdn.com rolls up under “Facebook”), keeping reports readable for non-technical reviewers.

How to Whitelist (Allow) a URL in CyBlock

Applies to: CyBlock · Allowing specific sites through your web-filtering policy.

If CyBlock is blocking a site you want to permit — or you want to allow a set of sites regardless of their category — there are two ways to whitelist (allow) URLs. Pick based on how many sites you’re allowing and whether you want them grouped:

Method 1 — White List exception in your policy. Fastest for a few specific sites within a category you’re otherwise blocking (e.g., block Search Engines but allow Google).
Method 2 — Custom category set to allow. Best when you have many sites to allow, they span different categories, or you want them grouped and tracked as their own category.

(This is about allowing sites through the web filter — “whitelist,” “allow,” “unblock,” “stop blocking.” It is not related to certificates or SSL inspection.)

Method 1 — Add a White List exception to your blocking policy

Use this to allow specific sites while still blocking the rest of their category.

Go to Web Management → Filter → Categories. The Control Web Categories page is displayed.
Make sure the category you want the exception in is blocked as intended (the white list carves an exception out of a blocked category).
Under the White List/Black List section, in the Allowed URLs box, type the URL you want to allow — for example, *.google.com.
To add multiple URLs, type the first and press ENTER, then type the next and press ENTER, repeating until all are entered.
Click Submit to apply.

How it behaves: an entry in Allowed URLs is permitted even though its category is blocked. For example, if you’ve blocked the Search Engines category but want Google, entering *.google.com in Allowed URLs allows Google while everything else in Search Engines stays blocked. The *. wildcard covers the domain and its subdomains.

Notes:

If a URL exists in both Allowed URLs and Blocked URLs, the blocked entry wins after you click Submit.
The Blocked URLs box is the reverse (a black list) — block specific sites while allowing the rest of their category.

Method 2 — Create a custom category and set it to allow

Use this to maintain a reusable group of allowed sites — handy when you’re allowing many domains or ones that span several categories.

Step A — Create the custom category and add your URLs

Go to Categorization → Customize → URLs. The Edit URLs page is displayed.
For Category Type, leave Custom selected (the default for creating a custom category).
Name the category:
- If you have no custom categories yet, type the name in the Add Category field (max 50 characters) — for example, Approved Sites.
- If custom categories already exist, use the Select Category field and choose Create Custom Category, then enter the name in Add Category.
In the Custom URLs box, type each domain you want to allow. To add multiple, type one and press ENTER, then the next and ENTER, and so on. Wildcards are supported (for example, *.example.com).
Click Submit.

Step B — Make sure your policy allows that category

Go to Web Management → Filter → Categories (the Control Web Categories page).
Confirm your new custom category is set to allow (not blocked) in the policy. Because it’s a category like any other, CyBlock filters it according to the policy — so leaving it unblocked allows every URL you added to it.

Notes:

Your custom category and URL changes override future Wavecrest URL List downloads, so your allowed sites persist through updates.
Adding a URL that already exists in another category moves it — it’s removed from the other category and placed in this one.
If you use SSL Inspection, custom categories are inspected by default.
Setting a category to allow (a filtering/policy action) is separate from a category’s classification — Acceptable / Unacceptable / Neutral — which only affects how activity is color-coded in reports, not whether it’s blocked.

Which method should I use?

A few specific sites within a category you’re blocking → Method 1 (White List). Quick and self-contained.
Many sites, sites across different categories, or a reusable “approved” list you’ll maintain over time → Method 2 (custom category set to allow). More scalable and reportable.

Verify it worked

Use Categorization → Check URL to confirm a URL resolves to the category/handling you expect — useful after Method 2 to verify your URLs landed in the custom category.

Cyfin & CyBlock Category Glossary — Category Definitions & Descriptions

Applies to: Cyfin and CyBlock · The complete list of content categories and what each one means.

Cyfin and CyBlock classify every website into a content category using the shared Wavecrest URL List — the categories are identical in both products. This is the full glossary of those categories and their definitions (the same list shown in-product under Help → Category Description).

Categories vs. classifications. A category describes the type of content (Gambling, Shopping, News). A classification is the policy label — Acceptable, Unacceptable, or Neutral — that your organization maps onto each category based on its acceptable-use policy. Category definitions are fixed (below); the classification mapping is configurable and set by you, so the same category may be Acceptable at one organization and Unacceptable at another.

Custom categories. Beyond the standard categories below, you can create your own custom categories for sites of particular interest (for example, intranet sites). That’s a separate task from the standard categories defined here.

The categories are grouped below the way Wavecrest organizes them — by the kind of concern they typically represent. Within each group they’re listed alphabetically.

Security Threats

Anonymous/Public Proxy — Sites that provide information on how to bypass filtering or monitoring systems, or provide a way to surf anonymously, i.e., access URLs by bypassing a Web filter or monitor.

Download Sites — Sites pertaining to the download of software. It includes sites that provide software downloads available for full or trial use at no cost or for a nominal, usually voluntary, fee, such as freeware and shareware.

File Sharing — Sites related to sharing and synchronizing documents, photos, videos, and other files in the cloud with other users and across multiple devices. Examples include Dropbox, Box, Hightail, and WeTransfer.

Malware — Sites that deploy viruses, worms, Trojan horses, spyware, and other malicious programs and/or provide hacking instructions in order to disrupt information handling and transaction processing, steal sensitive information, and gain access to internal systems. Sites may also appear official in order to get personal information and display unwanted advertisements.

Legal Liability

Cults/Occults — Sites that promote or provide information on occults, satanism, witchcraft, voodoo rituals, and other alternative religions.

Fantasy Sports — Sites that allow individuals to build teams that compete against each other based on statistics of real individual players or teams of professional sports.

Gambling — Sites where users can place bets or get more information on gambling. This includes online casinos, physical casinos (that are not hotels), offshore gambling, lottery, and sports advisory services.

Hate/Crime — Sites that promote hate speech, racism and racial bigotry, terrorist activities, criminal activities, and instructions on criminal activities.

Illegal Drugs — Sites that promote or advocate the use of illegal drugs or the recreational use of prescription drugs. This includes sites that offer or sell drug paraphernalia and advocate the cultivation and manufacture of illegal or recreational drugs. This excludes sites about prescription drugs, over-the-counter drugs, educational information on the dangers of illegal and recreational drug use, or rehabilitation services for drug addiction.

Pornography — Sites that contain sexually explicit material that intends to be sexually arousing. This includes explicit sex images and videos, nudity, adult video sales, sex toys, prostitution, and prurient sex information. It excludes nonprurient art, medically-related images or information, and legitimate sex education.

High Bandwidth

Audio Streaming — Sites that provide streaming or downloading of radio, music, MP3 files, or other audio content.

Games — Sites that offer online games, downloadable games, video games, computer games, and information on cheat codes for games. It also includes sites that provide gaming tips, chatting, leagues, and networking.

System/Application Updates — Sites that provide updates to operating systems and desktop applications. Examples include Microsoft Windows, Adobe Reader, and antivirus software.

Video Streaming — Sites that provide streams or downloads of television, movies, or other video content.

VoIP Services — Sites that enable users to make phone calls via the Internet or to obtain information or software for that purpose.

Cloud Services

Cloud Infrastructure — Sites that provide the capability to provision servers, storage, data center space, networks, operating systems, and other essential computing resources as an on-demand service where the user is able to deploy and run software. Examples include Amazon Web Services, Bluelock, and CA Technologies.

Cloud Storage — Sites that provide the ability to upload, access, organize, back up, and share files, photos, and documents from any computer or mobile device. These sites essentially act as a personal or business hard drive on the Internet. Examples include Google Drive, OneDrive, Carbonite, and Flickr.

Collaboration — Sites that provide for collaboration among employees by videoconferencing, online training, Web-based e-mail, productivity apps, etc. Examples include Skype for Business, WebEx, Gmail, and Office 365.

CRM — Sites related to customer relationship management (CRM), customer engagement, customer service and support, and help desk management services. Examples include Zendesk, Salesforce, and Needle.

Development — Sites that provide open source software for software development including code collaboration and review, as well as software distribution, and also promote agile development software and services. Examples include GitHub, JIRA Software, Confluence, and Bitbucket.

HR — Sites promoting human capital management software solutions including onboarding, payroll services, performance management, recruiting software, applicant tracking software, and talent management. Examples include Workday, SuccessFactors, NetSuite, and Jobvite.

Productivity Drains

Auctions/Classifieds — Sites that support the offering, purchasing, and bartering of goods or services between individuals.

Blogs — Personal Web sites posted by individuals or groups chiefly devoted to personal expression. It excludes topic-specific blogs. For example, a blog about professional football would be located in the Sports category.

Chat/Instant Messaging — Sites that provide chat or IM services to communicate in real time with other individuals.

Entertainment — Sites related to movies, television, theater, comic books, anime, theme parks, fan clubs, and other recreational activities. It also includes sites about celebrities, celebrity gossip, etc.

Job Search — Sites that advertise jobs or are related to employment, such as resume writing, job placement, and recruiting.

News — Sites that report on current news and events, such as TV networks and stations, radio networks and stations, news organizations, online newspapers, and general interest magazines. It includes local news, TV, and radio. It excludes special interest media with narrow targeted audiences (e.g., a site publishing current sports news is categorized as Sports).

Personal E-Mail — Sites offering online or Web-based e-mail services for personal use. This excludes enterprise e-mail services.

Personals/Dating — Sites that provide networking for online dating, such as dating services, matchmaking, mail order brides, personal ads, singles groups, and dating advice. It excludes pornographic activities and mate swapping.

Shopping — Sites related to physical and Web-based retail activities and stores, shopping aids, coupons, and information about shopping. It excludes B2B sales, government purchasing, and online auctions.

Social Media — Social sites containing personal profiles with a wide range of images and text for purposes of social interaction. It excludes social sites specific to dating/personals.

Sports — Sites that include information about athletic activities, sports scores and news, and sports teams and leagues. It includes sites that solely sell sports merchandise. Hunting and fishing are included in this category.

Stock Trading — Sites that provide information on the stock market, stock quotes, stock tickers, personal stock transactions, and stock market news.

Travel — Sites that specialize in travel arrangements, airlines, hotels, cruises, travel agencies, and car rentals. It excludes local transportation.

Weather — Sites related to weather, forecasts, and meteorology.

Business Operations

Advertisements/Tracking Sites — Sites associated with ad serving technology and companies, and Web traffic analysis — that is, URLs that track Web analytics.

Agriculture/Environment — Sites about farming, ranching (including large-scale farming/ranching equipment sales), forestry, gardening, horticulture, etc. It also includes air quality, water quality, conservation, waste management, ecology, and animal protection. It excludes retail grocery and food operations.

Business Services — Sites that offer services to help run everyday business, such as printing and publishing, office supplies and furniture, consulting, accounting services, and maintenance and janitorial services.

Financial — Sites related to online and offline banking services, investment services, loans, bankruptcy, money management, tax consulting, and credit cards.

High Tech — Sites that develop and/or sell computer software and hardware products, and provide information on computers, technology, the Internet (non-ISP), and technology-related companies.

Insurance — Sites that provide information about or offer life, health, dental, automobile, and homeowner’s insurance.

IT Services — Sites for companies that provide Internet access (ISPs), IT services, data center services, Web site hosting, cloud infrastructure services (IaaS), etc.

Legal Services — Sites pertaining to law enforcement, courts, lawyers, litigation, and civil rights. It also includes do-it-yourself sites providing legal advice and online legal forms for wills, divorce, incorporating a business, etc.

Manufacturing — Mining and traditional manufacturing sites, such as electronics, textiles, and plastics. It excludes energy and vehicle manufacturing, petroleum refineries, and food processing.

Marketing — Sites that provide marketing and advertising services, information on marketing and advertising strategies, and Web site design services.

Real Estate/Construction — Sites that promote renting, buying, or selling of properties, or provide information on home ownership, property management, land use, and home and yard maintenance services. It also includes building or housing construction — contractors, construction methods, and architecture services.

Shipping — Sites that offer material shipping, packing and shipping, and mailing services.

Telecommunications — Sites that provide telecommunications services and products, cable TV services, and wireless services and products.

Transportation/Storage — Sites about commuter transportation, local train, bus, and taxi services and schedules, freight transportation, and commercial trucking companies. It also includes storage facilities, portable storage and moving containers, vehicle storage, etc. It excludes long-distance travel and car rentals.

Utilities/Energy — Sites related to energy exploration, processing and refinement, and distribution and marketing. It includes fuel for transportation, electricity, natural gas, wind energy, and solar energy.

General Interest

Animals/Pets — Sites related to pet care, pet adoption, animal training, and animal shows. It also includes breed-specific sites.

Arts/Culture — Sites that promote arts and culture including sculpture, paintings and other visual art forms, literature, dance, ballet, opera, and performance art. This includes museums and galleries, and sites about lifestyles, hobbies, and self-improvement.

Education/Reference — Sites about schools, universities, educational facilities, vocational and adult education, distance education, preschools and day care, homeschooling, faculty, and alumni groups. It also includes libraries, online dictionaries, language translation, book sites, maps, census information, almanacs, engineering and technical reference, scientific information, environmental science, political science, and medical research.

Government — Federal, state, and local government sites and sites about government functions and services.

Groups/Forums — Sites dedicated to user groups (e.g., Google or Yahoo groups) or general-topic forums. It excludes content-specific forums; for example, the Adobe forum is located in High Tech.

Health/Medical — Sites about hospitals, clinics, physicians, service providers, medical services, health products, and pharmaceuticals. Also sites that promote healthy living through diet and exercise, the dangers of illegal and recreational drug use and substance abuse, and rehabilitation.

IP Addresses — Numerical IP addresses that have not been categorized. This category is a red flag: it alerts you that further action may be needed to resolve a problem (such as malware or spyware on a computer) or gives a more complete picture of all Web activity. For why you might see many hits to an IP address and what to do, see the IP Addresses Category document.

Kids — Sites aimed at children’s interests. It excludes sites that sell children’s toys (those are in Shopping).

Military — Military sites and sites related to bases and general military information. It excludes military news and history.

Noncategorized/Other — Sites not previously categorized by Wavecrest Computing. Any accessed sites not yet categorized are assigned to “Other.” Through the free OtherWise service, organizations can send Wavecrest a Top Noncategorized Sites report; Wavecrest analysts then research, identify, and categorize the most popular unidentified URLs and update the Wavecrest URL List accordingly.

Nonprofit Organizations — Sites for charitable organizations, veterans’ organizations, and emergency support organizations.

Politics — Sites related to politics, such as political advocacy, political party organizations, and candidate Web pages, or any sites promoting a political party. It excludes official government organizations.

Regional Information — Sites that provide local events and local interest topics.

Religion — Sites that advocate religion or provide information on religion and religious activities, including specific organizations or places of worship. It excludes cults, religious hatred, and religious bigotry.

Restaurants/Food/Alcohol — Sites related to restaurants, diners, cafes, bars, pubs, recipes, cooking instructions, food services, grocery, beverages, and alcohol. It excludes cooking equipment sales.

Search Engines — Sites that provide Web search services, search directories, and search portals.

Tasteless/Offensive — Sites that include offensive information or excessive profanity. It excludes sites that fit into the Pornography and Hate/Crime categories.

Vehicles — Sites that sell and/or provide information about bicycles, automobiles, trucks, motorcycles, boats, and aircraft. It includes vehicle design and manufacturing, marketing and sales, maintenance and restoration, and vehicle clubs.

Weapons — Sites that sell, review, describe, or provide information on weapons, such as guns, knives, bombs, or martial arts devices. It excludes sites solely about hunting or hunting tools such as rifles and bows and arrows.

Additional categories

Artificial Intelligence — Websites employing AI technologies such as machine learning and deep learning to provide human-like services. This includes platforms offering chatbots, productivity tools, summarizers, transcription services, no-code solutions, and multimedia editing. It specifically targets sites actively hosting these AI functionalities, not just providing AI information. (A newer category; not yet reflected in every grouping.)

Cyfin & CyBlock Report Glossary — Report Definitions & Descriptions (Sessions-Based Reporting)

Applies to: Cyfin and CyBlock · A reference to what each standard report shows and when to use it.

Cyfin and CyBlock share the same reporting feature — the same reports, the same paths, and the same metrics in both products. Everything below applies identically to either one. This is the glossary of the standard reports — their definitions / descriptions — reflecting the current sessions-based reporting direction. Sessions are the primary metric in high-level reports; Hits appear at the deepest drill-down. (If you’re looking for the older “Visits” or “Time Online” metrics, see What happened to Visits and Time Online? at the end.)

How to use the reports together

There are two ways in, and most reviews use both in sequence:

Proactive / summary reports survey the whole population — who is most active, which sites and categories dominate. Use these to spot a user ID or a site of interest. (Top Users, Top Web Sites, Site Analysis, Site Audit Summary.)
Session investigation reports take a single user ID of interest and reconstruct exactly what that person did, drilling from a high-level summary down to individual URLs. This is the pathway for a focused review of one user — for example an employee web-activity investigation. (Session Analysis → Session Audit Summary → User Audit Detail.)

A typical review: scan the summary reports, find an ID or site that stands out, then run a session investigation on that specific ID.

Report metrics at a glance

Reports use two metric families, and which one you see depends on the report:

Session reports (Session Analysis, Session Audit Summary, User Audit Detail) use Sessions and Session Duration. Session Duration is available only in these reports.
All other reports are hit-based — they quantify activity by Hits and Bytes. They no longer include Visits or Time Online; both of those metrics have been retired.

So if you need duration, use a session report; the hit-based summary and detail reports measure activity by hit and byte volume.

Session Investigation Reports — the investigation pathway

These three reports are three levels of detail on the same user and period — you start high and drill down by clicking hyperlinks. Sessions reconstruct scattered firewall/proxy connection records into readable browsing events, filtering out non-human background traffic (OS updates, telemetry, ad trackers) so the report reflects what a person actually did, not raw log volume.

Session Analysis (Level 1 — start here)

A complete summary of one user’s web activity across the full investigation period: every application/site accessed, session counts, session duration, and content categories, with color-coded classifications. Ranked by session count so areas of concern surface first. Clicking an application opens the Session Audit Summary for that site. This is where every investigation begins.

Session Audit Summary (Level 2)

Narrows to one selected application and lists every session the user had on it — session start, session stop, and duration for each, plus the device IP address and category. Shows the pattern of access: how many sessions, how long each lasted, and whether activity clustered at particular times. Clicking a session opens the User Audit Detail.

User Audit Detail (Level 3 — the evidence)

The most granular level: every URL logged during one selected session, in chronological order, with timestamp, category, classification, and full clickable URL. Includes a URL search filter and a Total Denied Requests count. This is the evidentiary foundation for any formal action. Note: the list includes background and site-generated requests, so not every URL is a deliberate click — the session grouping above it is what isolates meaningful activity.

Summary / Proactive Reports

Use these to survey activity and identify who or what to investigate.

Site Analysis

A high-level, hit-based audit of activity from several perspectives — by classification (Acceptable / Unacceptable / Neutral), by category, by group, by user, and by user within each category, measured in hits and bytes. Individual sites are not identified. Good for broad or focused audits of activity volume across the population.

Top Users

Lists the most active users by activity volume (hits, denied hits, and bytes). An excellent screening tool: it surfaces the users with the highest activity so you can drill down or launch a session investigation on those IDs.

Top Web Sites

Lists all accessed sites (domains) with their category, hits, and bytes, sorted by activity volume. Individual user IDs are not shown, but each site links out for further analysis. Highlights the most-accessed sites; inappropriate ones can prompt deeper investigation or blocking.

Site Audit Summary

Lists the top groups and users who accessed a particular site (can be run for more than one site), with hit and byte totals and hourly breakdown, and a link to each user. A quick, summarized look at who is using a given site the most.

Detail & Audit Reports

Targeted deep-dives into a category, a site, search terms, or blocked requests.

Category Audit Detail

A detailed analysis of one selected category (e.g., Pornography): all URLs for each user who accessed that category, plus the top users, groups, and hourly activity within it. Useful for auditing possible misuse concentrated in a specific category.

Site Audit Detail

Focuses on one or more specific sites: every record to those URLs, listed chronologically for all users, with IP address, user, and full URL, plus top-group/user/hourly summaries. A complete view of who accessed a given site and what they did.

Search Term Audit Detail

Shows the search terms users entered on popular search engines (Google, etc.), with IP address, user, date/time, and search engine. A forensic aid — indicates how many search terms were entered and by whom.

Denied Requests

By category, shows which users were denied access to sites or pages during the period. Individual users are identified; specific URLs are not. If web filtering is enabled, this verifies it’s working and flags attempts to reach blocked content.

Denied Requests Detail

The URL-level version: the specific URLs to which each user was denied access, by user, in the requested category. A useful supplement to individual user audits, showing the number and type of blocked requests.

IT / Bandwidth Reports

Focused on network and bandwidth rather than individual behavior.

Network Information

Total hits, byte trends, and total bytes broken down by classification, category, group, IP address, and hourly activity. No individual users or sites are identified — it keeps the focus on bandwidth, helping admins spot network performance issues.

Site Analysis Bandwidth

Like Site Analysis, but focused on bandwidth consumption instead of hit counts: trend in bytes and total bytes by classification, category, group, user, and user within category. Helps IT manage bandwidth and identify the heaviest users per category.

Top Bandwidth Sites

The top bandwidth-consuming sites for a selected group, each with its category and byte consumption, sorted highest-first. Individual users are not shown. Quickly identifies which sites are driving bandwidth so unwarranted consumption can be investigated or blocked.

Key terms

Session — A period of continuous user activity with a single application/site, reconstructed from the log. Opens at the first qualifying activity and closes after a set inactivity period (commonly 10 minutes), and must meet minimum thresholds to be counted. Session count is the primary metric in high-level reports.

Session Duration — Elapsed time from the first to the last record within a session (HH:MM:SS) — meaningful active time, not raw connection time. Available only in the session reports. It replaces the retired Time Online metric.

Sessions % — A site’s or category’s share of all sessions, shown as a number and a classification-colored bar.

Session Duration % — A site’s or category’s share of total reporting-period time. A site with few sessions can still show a high duration % if those sessions were long.

Hit — A single log record. One page load generates many hits (images, scripts, stylesheets, background requests). Hits are the raw material sessions are built from and appear at the deepest drill-down level, not as a headline metric.

Application / Web Site (App/Site) — A recognized web service grouping all its related domains under one friendly name (e.g., fbcdn.com rolls up under “Facebook”), so reports stay readable.

Category — The product’s content category for a site (e.g., Video Streaming, Auctions/Classifieds, Shopping, News).

Classification — The policy label applied to categories: Acceptable (green), Unacceptable (orange), or Neutral (gray). The category-to-classification mapping is set by your organization’s acceptable-use policy.

Denied Request — A request blocked by your proxy or firewall before reaching its destination. A non-zero count means blocked content was attempted.

Bytes — Volume of data transferred (KB or MB).

Ingestion — Loading raw proxy/firewall log data into Cyfin for a user and period; reporting begins after ingestion completes. By default Cyfin excludes known non-human domains during ingestion; this can be disabled if a full traffic record is needed.

User ID — The network login identifier used to attribute activity to an individual across all reports (e.g., firstname.lastname).

What happened to Visits and Time Online?

Customers on legacy reports may still expect the Visit and Time Online metrics. Both have been retired:

Visits have been upgraded to Sessions. Sessions capture a user’s continuous engagement with a site or app, which gives a clearer, more accurate picture than a single-interaction count in today’s dynamic web — where one page pulls content from many servers and mixes in automated background traffic.
Time Online has been replaced by Session Duration, which is available only in the session reports.

The hit-based reports (everything outside the session reports) now measure activity by Hits and Bytes — they no longer show Visits or Time Online. Hits and Visits were the right tools for their time; sessions build on that foundation. This is a response to how the web changed, not a correction of past reporting.

Installing the Wavecrest Root Certificate on Client Machines for CyBlock SSL Inspection

Applies to: CyBlock (proxy SSL inspection) · Area: Settings → Proxy → SSL Inspection Where it happens: each end-user’s computer

Which certificate are you looking for? (There are three — this is #3)

They’re easy to confuse. The quick tell is whose machine the certificate goes on and what it’s for:

Console / UI certificate — installed on the server, so administrators reach the Cyfin/CyBlock admin console over validated HTTPS. See Installing Your Own SSL Certificate on the Cyfin/CyBlock Web Interface (Secure Interface).
Proxy SSL certificates (Settings → Proxy → SSL Certificates) — client-authentication certificates the CyBlock proxy uses internally during inspection. Advanced/optional; CyBlock proxy only.
Wavecrest root certificate on end-user machines — this article. Installed on every user’s computer so their browser trusts CyBlock’s inspected HTTPS connections and SSL inspection works without certificate errors.

If your users are getting certificate warnings on HTTPS sites after you turned on SSL inspection, you’re in the right place — this is #3.

Why this is required

When SSL inspection is enabled, the CyBlock proxy decrypts each user’s HTTPS connection and re-secures it using a certificate signed by the Wavecrest root certificate authority (CA). If a user’s computer doesn’t already trust that Wavecrest root, the browser treats every inspected HTTPS site as untrusted and shows a certificate warning.

Installing the Wavecrest root certificate into the machine’s Trusted Root Certification Authorities store (or the browser’s own store, for Firefox) makes those inspected connections validate cleanly — no warnings. This is why the manual lists “Install the Wavecrest Certificate” as a required step, and why it must be done on each client whose traffic you inspect.

Do this before you enable SSL inspection, so users never see the warning in the first place.

Step 1 — Download the Wavecrest certificate

The certificate is served by your CyBlock instance, so always get it from the in-product link rather than a hard-coded address:

In CyBlock, go to Settings → Proxy → SSL Inspection.
Click the “Click here to install the Wavecrest Certificate” link on that screen. It points to your instance’s certificate file (for cloud customers this is your region’s host; for on-prem/VM it’s your own CyBlock server).
Save the certificate file — nokeywavecrest.crt — somewhere you can reach it during install. You’ll distribute this same file to client machines.

If you can’t locate the link, Wavecrest Technical Support can provide it: support@wavecrest.net or (321) 953-5351, Ext. 4.

Step 2 — Install the certificate on client machines

Pick the method that matches how your users’ machines are managed. For a domain environment, the Active Directory / GPO method (below) installs to all machines at once and is the recommended approach.

Windows 10 / 11 — single machine (manual)

Copy nokeywavecrest.crt to the machine and double-click it, then click Install Certificate.
Choose Local Machine (installs for all users on that PC; requires admin) and click Next.
Select Place all certificates in the following store, click Browse, choose Trusted Root Certification Authorities, and click OK → Next → Finish.
Click Yes on the security warning to confirm the root install.

Google Chrome and Microsoft Edge on Windows use this system store, so no separate steps are needed for them. (Firefox is separate — see below.)

Windows — all domain machines via Active Directory (GPO)

On the domain controller, open Group Policy Management.
Edit the GPO you use for client machines (for example, Default Domain Policy).
Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Trusted Root Certification Authorities.
Right-click it, choose All Tasks → Import, and complete the wizard, selecting nokeywavecrest.crt and the Trusted Root Certification Authorities store.
Client machines pick up the certificate on their next Group Policy refresh.

macOS — single machine (Keychain Access)

Copy nokeywavecrest.crt to the Mac and double-click it to open Keychain Access.
Add it to the System keychain (requires an admin login) so it applies to all users.
In Keychain Access, find the Wavecrest certificate, double-click it, expand Trust, and set When using this certificate to Always Trust. Close the window and authenticate to save.

Safari and Chrome on macOS use the system keychain; Firefox does not (see below).

Firefox — any operating system (its own certificate store)

Firefox does not use the OS store, so it needs the certificate imported separately on each machine (or distributed via Firefox enterprise policy):

Open Firefox → Settings → Privacy & Security → Certificates → View Certificates.
On the Authorities tab, click Import and select nokeywavecrest.crt.
Check Trust this CA to identify websites, click OK, and close the dialog.

Step 3 — Verify

On a client where you installed the certificate, browse to an HTTPS site in a category you’ve set to Inspected.
Confirm the page loads with the padlock and no certificate warning.
(Optional) View the certificate details — the issuer chain should show Wavecrest as the signing authority, confirming the inspected connection is trusted.

Inspected traffic can then be viewed in the Real-Time Web Monitor and in audit reports.

Important notes

Install before enabling inspection. Turning on SSL inspection before the root certificate is on client machines is the most common cause of “certificate error on every site” reports.
Some applications may still error. Apps that don’t use the operating system’s certificate store (they ship their own trust list or use certificate pinning) can fail under SSL inspection even after the root is installed. If you hit this, contact Wavecrest Technical Support at support@wavecrest.net or (321) 953-5351, Ext. 4.
This is a per-client step. Every machine whose HTTPS traffic you inspect needs the root certificate. GPO (Windows) and Firefox enterprise policy scale this to many machines at once.
Not the console/interface certificate. Installing your own certificate to reach the CyBlock admin UI over HTTPS is a different task — see the Secure Interface article.