FAQ Archive - Page 2 of 3 - Wavecrest Knowledge Base

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.

Installing Your Own SSL Certificate on the Cyfin / CyBlock Web Interface (Secure Interface)

Applies to: Cyfin and CyBlock · Area: Settings → Secure Interface

The Secure Interface screen and this procedure are the same in both Cyfin and CyBlock. Where they differ, it’s noted inline.

Is this the article you need? This explains how to install your own SSL/TLS certificate on the product’s web interface so that when you connect to the Cyfin/CyBlock console over HTTPS, your browser shows a valid, trusted certificate that matches your domain — no security warning.

The one distinction that matters here: accessing the UI vs. inspecting user traffic. This article is only about a certificate for accessing the admin console/UI over validated HTTPS. It has nothing to do with inspecting your users’ web traffic.

If you’re trying to inspect users’ HTTPS traffic instead, that’s SSL inspection — a different thing entirely:

In CyBlock, SSL inspection is a proxy-only feature with its own screen: Settings → Proxy → SSL Certificates. Those are the client-authentication certificates the proxy uses to decrypt and inspect HTTPS traffic. That screen has nothing to do with reaching the UI, and it does not exist in Cyfin. If that’s what you want, go there — not the Secure Interface screen below.

In Cyfin, SSL inspection isn’t a Cyfin screen at all; it’s enabled on your firewall — see the SSL Inspection article.

The common case: use your own certificate that matches your domain

By default, the product serves its web interface with a built-in Wavecrest certificate. Because that certificate isn’t issued to your domain by a CA your browsers already trust, connecting over HTTPS shows a “not secure” / name-mismatch warning.

Most customers therefore install their own certificate — one issued to the exact hostname they use to reach the console (for example cyfin.yourcompany.com or cyblock.yourcompany.com, or a wildcard like *.yourcompany.com). Once installed and enabled, browsers show a valid certificate and the padlock, with no warning.

There are two ways to do it, depending on what you already have:

You already hold a certificate + private key issued to that hostname (for example a wildcard cert) → Option A.
You need the product to generate a signing request for your CA to issue against → Option B.

Before you begin

You’ll need administrator access.
Have the fully qualified domain name (FQDN) users will use to reach the console.
Your certificate and private key must be in PEM format.
Installing or changing the interface certificate triggers an automatic service restart — plan a brief maintenance window.

Option A — Install a certificate you already have (PEM)

Go to Settings → Secure Interface.
Click the edit (pencil) icon next to Current Certificate.
Under Certificate Type, select Custom.
Paste your signed certificate into Certificate Data (PEM), then append your private key at the bottom of the certificate in the same field.
Click Install. The product applies the certificate and restarts the service.

Continue to Enable the secure (HTTPS) connection.

Option B — Generate a CSR in the product and have your CA sign it

Use this when you don’t yet have a certificate and want your CA to issue one for the console hostname.

Go to Settings → Secure Interface.
Click Certificate Signing Request and complete the form:
- Domain Name (required) — the full domain of the server (for example cyblock.yourcompany.com).
- Country — 2-digit country code.
- State / City — if applicable.
- Organization — your organization name (defaults from the License screen).
- Email — the person responsible for the server (defaults to the current login’s email).
- Organization Units — optional departments/groups (for example “IT Group”); type next to New Unit and click +. Multiple units can nest (for example a “Security Audit” unit under “IT”). Remove All clears the box.
Click Generate. The product produces the CSR and private key in PEM format.
Save the private key in a secure location, then forward the CSR to your CA for signing.
When the CA returns your signed certificate:
- Return to Settings → Secure Interface and click the edit icon next to Current Certificate.
- Under Certificate Type, select Custom.
- Paste the signed certificate into Certificate Data (PEM) and append the private key you saved at the bottom.
- Click Install. The product applies the certificate and restarts the service.

Continue to Enable the secure (HTTPS) connection.

Enable the secure (HTTPS) connection

Installing the certificate is only half the job — you also enable HTTPS on the interface.

In Settings → Secure Interface, configure the connection type.
HTTP is enabled by default. Keep it (optionally changing the Port), or select Disable to turn it off.
For HTTPS, select Enable to use a secure browser connection. The Port is prefilled with a recommended value; change it if needed.
(Recommended the first time) Enable both HTTP and HTTPS so you can confirm the certificate loads before turning HTTP off.
With both enabled, the Force HTTP to HTTPS Redirect option appears. Select Enable so HTTP visitors are redirected to HTTPS.
Click Submit, then Continue to restart the service.

Verify

Browse to https://<your-console-domain>:<https-port>.
Confirm the browser shows the padlock and a valid certificate issued to your domain, with no warning.
Check the certificate details to confirm it’s your certificate, not the default Wavecrest one.

CyBlock note: when switching from an invalid to a valid certificate, you may need to close and reopen the browser for the address bar to show the updated certificate status.

If you still see a warning, the usual causes are a domain mismatch (the certificate isn’t issued to the hostname you’re browsing to) or an untrusted signing CA — common with an internal/enterprise CA, whose root must be distributed to client machines so browsers trust it.

Alternative: keep the default Wavecrest certificate

If you don’t install your own certificate, you can instead distribute the built-in Wavecrest root so clients trust the default certificate. From Settings → Secure Interface, click Wavecrest Certificate to download the Root Certificate Authority, and see the Wavecrest Certificate Installation Guide for how to install/distribute it. Most customers prefer their own certificate (above) because it matches their domain and validates without extra client-side distribution.

URL List Options

Cyfin / CyBlock — E-Mail Settings FAQ

Configuring and Testing Your E-Mail Settings

Why Isn’t My E-Mail Test Working?

When setting up e-mail in Cyfin or CyBlock, the E-Mail Settings page has both a Test button and a Submit button. It may seem natural to click Test first to verify your settings — but the Test button will not work until your settings have been saved first.

You must click Submit before clicking Test.

The Correct Order

Step 1 — Fill in your e-mail settings

Enter your e-mail configuration on the E-Mail Settings page:

Administrator’s Address — the address Cyfin will send reports and alerts to
Server Name — your outgoing mail server (SMTP) hostname
Server Port — typically 25, 465, or 587 depending on your mail server
Use SSL — check this if your mail server requires an encrypted connection
Does Server Require Authentication — select Yes and enter credentials if your SMTP server requires a login
Use Server Alias in E-Mail — optionally display a friendly sender name (e.g., “Cyfin”) in outgoing messages

Step 2 — Click Submit

Click the Submit button at the bottom of the page to save your settings. You must do this first, even if you intend to test right away.

Step 3 — Click Test

Once your settings are saved, click the Test button to send a test e-mail to the Administrator’s Address. Check that inbox to confirm the message was received.

If the test e-mail does not arrive, review your settings and click Submit again before re-testing.

Quick Reference

Button	What It Does	When to Use It
Submit	Saves your e-mail settings	Always first — before testing
Test	Sends a test e-mail using the saved settings	After Submit has been clicked

Common Mistake

Clicking Test without clicking Submit first will either produce an error or test against the previously saved settings — not the values currently shown on screen. Always save with Submit before running a test.

For additional assistance, contact Wavecrest Technical Support.

CyBlock — Users Not Being Identified (Missing User IDs / Browser Login Prompt)

Applies to: CyBlock · When activity isn’t logged by username, or employees get browser login prompts.

CyBlock identifies users automatically via NTLM as their traffic passes through the proxy. When that identification fails, you’ll see one or both of these symptoms:

Usernames are blank or show as IP addresses in CyBlock activity and reports.
Employees get a pop-up username/password prompt in Edge or Chrome when browsing — even to everyday sites.

Both symptoms mean CyBlock isn’t successfully identifying the user. Work through the two areas below in order: first confirm CyBlock’s own authentication rule, then (if users are being prompted) the Windows/browser configuration.

(If usernames are appearing but all fall under Ungrouped IDs, that’s a different issue — IDs are captured but not organized into your Groups and IDs tree. See the Terms Glossary for Ungrouped IDs.)

Step 1 — Check the CyBlock Authentication Manager rule

Start here. CyBlock needs an NTLM authentication rule to identify users.

Go to User Management → Authentication → Authentication Manager.
Open the Rules tab.
Confirm there is a rule with:
- Type: NTLM, and
- Network definition: *Default

If that NTLM rule is present and correct, CyBlock is set up to identify users, and the problem is most likely on the Windows/browser side — continue to Step 2. If the rule is missing or its network definition is wrong, correcting it here is the fix.

Step 2 — If employees are being prompted to log in (Windows/browser configuration)

What’s happening and why

CyBlock identifies users silently by asking the browser to confirm the employee’s Windows login as traffic passes through the proxy — normally invisible to the user. Recent Windows 11 and Edge/Chrome security changes tightened the rules around this automatic sign-in, so the browser now needs to be explicitly told it’s safe to release Windows credentials to the CyBlock proxy. If it isn’t, the browser either prompts the employee for credentials or skips identification entirely (leaving usernames blank).

This is a Microsoft security change, not a CyBlock defect. The fix is applied by your IT administrator via Group Policy (GPO), which pushes the settings to all computers at once. Getting cloud-proxy NTLM working reliably requires two GPO controls — both must be in place.

Which browsers need configuration

Microsoft Edge — requires configuration
Google Chrome — requires configuration
Internet Explorer — not affected
Firefox — uses a separate process; contact Wavecrest Support if Firefox is in use

Layer 1 — Allow the proxy to request Windows authentication (AuthServerAllowlist)

This tells Edge and Chrome that the CyBlock proxy is allowed to request integrated Windows authentication.

Microsoft Edge (GPO):

Open Group Policy Management Console (gpmc.msc) and edit a GPO linked to the OU containing your computers.
Go to Computer Configuration → Administrative Templates → Microsoft Edge → HTTP authentication.
Open Configure list of allowed authentication servers, set it to Enabled.
In the value field, enter: *.cloud.cyblock.com,cloud.cyblock.com
Click OK.

(First-time setup: download the Edge policy templates from https://www.microsoft.com/en-us/edge/business/download and copy msedge.admx / msedge.adml into your domain controller’s Central Store.)

Google Chrome (GPO):

In the same or a linked GPO, go to Computer Configuration → Administrative Templates → Google → Google Chrome → HTTP authentication.
Open Authentication server allowlist, set it to Enabled.
In the value field, enter: *.cloud.cyblock.com,cloud.cyblock.com
Click OK.

(Registry equivalent, for non-domain machines — apply as a computer/HKLM policy:

Edge: HKLM\SOFTWARE\Policies\Microsoft\Edge → AuthServerAllowlist (REG_SZ) = *.cloud.cyblock.com,cloud.cyblock.com
Chrome: HKLM\SOFTWARE\Policies\Google\Chrome → AuthServerAllowlist (REG_SZ) = *.cloud.cyblock.com,cloud.cyblock.com)

Layer 2 — Move the proxy into the Local Intranet zone (Site to Zone Assignment)

Even with Layer 1 set, Windows checks the security zone of the proxy host before it will release credentials automatically. Because cloud.cyblock.com is an internet-hosted address, Windows treats it as the Internet zone, and Internet-zone hosts prompt the user instead of signing in silently. The proxy must be reassigned to the Local Intranet zone for automatic authentication to work.

GPO:

Go to Computer Configuration → Policies → Administrative Templates → Windows Components → Internet Explorer → Internet Control Panel → Security Page → Site to Zone Assignment List.
Set it to Enabled, then click Show and add:
- Value name: cloud.cyblock.com
- Value: 1 (1 = Local Intranet zone)
Click OK.

(Even though the GPO path says “Internet Explorer,” this zone list is also read by Edge and Chrome for the integrated Windows authentication credential decision.)

(On-premise / appliance deployments: substitute your own internal proxy hostname for cloud.cyblock.com. Whether the zone step is needed depends on whether your proxy hostname already resolves to the Local Intranet zone — contact Wavecrest Support if unsure.)

Single-machine test (before a full GPO rollout)

To confirm the two-layer fix on one affected machine before deploying via GPO, run these as Administrator, then fully restart the browser and check the CyBlock log for usernames:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\cloud.cyblock.com" /v https /t REG_DWORD /d 1 /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v AuthServerAllowlist /t REG_SZ /d "*.cloud.cyblock.com,cloud.cyblock.com" /f

Apply and verify

Run gpupdate /force on a test machine (or wait for Group Policy to refresh).
Fully restart the browser — these policies require a complete browser restart, not just a new tab.
Confirm the policy is active: open edge://policy (Edge) or chrome://policy (Chrome) and check that AuthServerAllowlist shows the correct value.
Browse to any external site, then check the CyBlock activity log for the username.
If it’s still not working, check Event Viewer → Applications and Services Logs → Microsoft → Windows → GroupPolicy for GPO application errors.

Troubleshooting

Symptom	Likely cause	Action
Usernames blank, no NTLM rule found	CyBlock auth rule missing	Add/correct the NTLM rule (`*Default`) in Authentication Manager (Step 1)
Login prompts persist after GPO deployed	Browser not fully restarted	Close and reopen all browser windows
Usernames still blank after Layer 1	Proxy still in Internet zone	Apply the Layer 2 Site-to-Zone assignment
Policy not showing in `edge://policy`	Edge ADMX templates not installed	Install templates in the Central Store on your domain controller
Only some computers affected	GPO linked to wrong OU	Ensure the GPO is linked to the OU with computer accounts, not user accounts

Additional notes

Apply these as computer policies (HKEY_LOCAL_MACHINE), not user policies.
Multiple proxy addresses can be listed, comma-separated, no spaces.
This is part of Microsoft’s ongoing phase-out of older authentication methods; Wavecrest will update guidance as the rollout continues.
For help, contact support@wavecrest.net.

Disabling/Blocking QUIC Protocol in Your Network

Q: How can I disable QUIC for all employees using Windows Group Policy?

A: You can disable QUIC for employees using Group Policy settings for supported browsers like Google Chrome and Microsoft Edge. Here’s how:

For Google Chrome:
1. Open Group Policy Editor: Press Win + R, type gpedit.msc, and hit Enter.
2. Navigate to Chrome Policies: Go to Computer Configuration or User Configuration > Administrative Templates > Google > Google Chrome.
3. Set QUIC Policy: Find “Allows QUIC protocol” or “Experimental QUIC protocol”.
  - Edit to set it to Disabled.
4. Apply and Update: Click Apply, then OK. Use gpupdate /force or restart machines for immediate effect.
For Microsoft Edge:
1. Open Group Policy Editor: As above.
2. Navigate to Edge Policies: Go to Computer Configuration or User Configuration > Administrative Templates > Microsoft Edge.
3. Set QUIC Policy: Look for “Allows QUIC protocol”.
  - Edit to set it to Disabled.
4. Apply and Update: Click Apply, then OK. Update policy or restart machines.

Q: Can I block QUIC at the firewall level?

A: Yes, you can also block QUIC at your firewall by blocking UDP traffic on port 443:

Firewall Configuration:
- Block UDP Port 443: Configure your firewall to block outgoing UDP traffic on port 443. This will effectively prevent QUIC traffic since QUIC typically uses UDP over this port.
- Considerations:
  - Ensure this does not interfere with other necessary UDP traffic on the same port or other services that might use UDP 443.
  - This approach will block QUIC for all applications, not just browsers, which might be more comprehensive but also more disruptive if not all UDP 443 traffic is intended to be blocked.

Q: How can I verify if the QUIC policy has been applied?

A:

For Chrome: Navigate to chrome://policy/ in the browser to check if the QUIC policy is listed as “Disabled”.
For Edge: Use edge://policy/ to confirm the policy setting.

Q: What should I consider when disabling or blocking QUIC?

A:

Performance Impact: Disabling or blocking QUIC might affect browsing speed or functionality on websites optimized for QUIC.
Policy Updates: Policy names or locations might change with browser updates; keep your GPOs and firewall rules updated.
Fallback: Browsers will fall back to HTTP/2 or HTTP/1.1, potentially less performant.
Network Level: Blocking at the firewall is a broad approach affecting all QUIC traffic, so careful planning is needed.

Q: Will disabling QUIC affect all applications?

A: No, browser policies mainly affect Chrome and Edge. Blocking at the firewall will impact all applications using QUIC on UDP 443.

How to configure syslog on FortiGate

Below are the steps that can be followed to configure the syslog server:

From the GUI:

Log into the FortiGate.
Select Log & Report to expand the menu.
Select Log Settings.
Toggle Send Logs to Syslog to Enabled.
Enter the Syslog Collector IP address.
Select Apply.

If it is necessary to customize the port or protocol or set the Syslog from the CLI below are the commands:

config log syslogd setting 
    set status enable
    set server "192.168.1.19"
    set mode udp
    set port 514 
end

To establish the connection to the Syslog Server using a specific Source IP Address, use the below CLI configuration:

config log syslogd setting
    set status enable
    set server "192.168.1.19"
    set source-ip "192.168.1.1"
    set mode udp
    set port 514
end

The source ‘192.168.1.1’ can be any IP address of the FortiGate’s interface that can reach the syslog server IP of ‘192.168.1.19’ in the above example.

The ping and ping-options command from the CLI can be used to check basic connectivity to the Syslog server from a specific source IP.

exec ping-options source 192.168.1.1
exec ping 192.168.1.19
PING 192.168.1.19 (192.168.1.19): 56 data bytes
64 bytes from 192.168.1.19: icmp_seq=0 ttl=255 time=0.2 ms
64 bytes from 192.168.1.19: icmp_seq=1 ttl=255 time=0.1 ms
64 bytes from 192.168.1.19: icmp_seq=2 ttl=255 time=0.1 ms
64 bytes from 192.168.1.19: icmp_seq=3 ttl=255 time=0.1 ms
64 bytes from 192.168.1.19: icmp_seq=4 ttl=255 time=0.1 ms

--- 192.168.1.19 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 0.1/0.1/0.2 ms

Disk Usage Warning

If you receive a “Disk Usage Warning” email, you can take several steps to manage this issue. Some solutions, like reducing the retention period, can be implemented on your own without needing support. However, if increasing storage capacity becomes necessary, please schedule a call with support for further assistance.

Cyfin or CyBlock Disk Usage Warning

Steps customers can take on their own:

Navigate to: Data Management > Log Data Source > Delete.
- Adjust the time frame for scheduled deletions to reduce the amount of stored data. This cleanup process will run overnight.
- Alternatively, set the process to manual, choose “Delete”, and then revert to scheduled deletions after the cleanup.

Note: These actions will not affect any already ingested reporting data; This only remove the raw logs used during the data ingestion process.

Metric Server Disk Usage Warning

Your disk usage warning could be due to an increase in stored data during the retention period or because initial storage estimates were underestimates, consider the following options:

Option 1 (Steps customers can take on their own):

If you don’t want to allocate additional storage:

Reduce the metric server’s storage limit to decrease retention time:
- Navigate to: Data Management > Report Database > Configuration > Settings.
- Reduce the storage limit (e.g., from 1 year to 6 months, from 6 months to 3 months, etc.).

Option 2 (Requires Assistance from Support):

If you want to maintain the existing retention period and need to increase storage based on current data growth:

Schedule a call with support to help expand your currently configured storage.

Understanding Data Storage for Cyfin: Cloud and On-Premises Environments

When using Cyfin, it’s important to understand how we handle and store data, whether you’re running in our cloud environment or deploying an on-premises version. This article outlines the key points for both types of deployments and explains the storage of processed and enhanced data—not raw log data.

Data Processing and Storage in Cyfin

Cyfin’s primary function is to receive a syslog data stream from firewalls or other supported sources, and then process, parse, and enhance this data. During this process, Cyfin only ingests the specific fields required for analysis and reporting. Once the data is ingested, we apply compression and store only the valuable, enriched data used for generating employee-focused web usage reports that are manager and HR-friendly. Importantly, Cyfin does not store the original raw log files sent to us; instead, we store the processed and optimized data ready for reporting and analysis.

Cloud Environment Customers: Storage Options and Costs

If you are running Cyfin in our cloud environment, your data will be securely stored within the Cyfin metric cloud ecosystem. We offer two types of storage based on your operational needs:

Cold Storage: This option is suitable for customers who do not require real-time access to their data. It offers a lower cost per gigabyte, though retrieval times may be slower. Cold storage is ideal for customers who initiate investigations based on internal requests rather than constant monitoring.
Hot Storage: For customers who need faster access to their data, hot storage provides quicker retrieval times at a higher per-gigabyte rate. This option is best suited for customers who require immediate access to the data for monitoring or investigations.

You also have the flexibility to combine both hot and cold storage to optimize cost and performance based on your retention policy. For example, if your retention policy is one year, you could use hot storage for the first three months to ensure rapid access to more recent data for investigations, and cold storage for the remaining nine months, where quick access is less critical. This hybrid approach allows you to balance speed and cost depending on your data access needs over time.

Since each customer’s storage requirements can vary based on web resource usage and the fields we ingest, we recommend starting with a proof of concept to determine the actual storage required. To obtain an accurate storage estimate for your retention policy (such as one year), you will need to syslog your live data stream and allow Cyfin to ingest data for a sufficient period. This will give you a clearer idea of your peak and slow ingestion periods and help you properly estimate long-term storage needs.

On-Premises VM Customers: Provisioning Your Own Storage

For customers installing Cyfin on an on-premises virtual machine (VM), you will need to provision storage in your own environment. Similar to our cloud offering, you will be responsible for storing the processed and enhanced data, not the raw log files. We recommend evaluating the product by syslogging your live data stream over a period long enough to capture both peak and slow periods. This will help you estimate the storage needed to retain data for your required retention policy, typically one year.

Just like with our cloud-based offering, on-premises customers can also opt to combine hot and cold storage for a more tailored solution. For instance, you might provision hot storage for data you need immediate access to and cold storage for older data that you don’t access frequently, helping you manage costs without sacrificing performance when it matters most.

Conclusion

Understanding the storage requirements for Cyfin is essential for optimizing both cost and performance. Whether you choose our cloud-based storage options or an on-premises deployment, rest assured that only the processed and enhanced data is stored, and we can tailor storage solutions to fit your specific needs. You also have the flexibility to combine hot and cold storage to balance retrieval speed and cost over time. To accurately assess storage for your retention policy, it’s critical to evaluate Cyfin by ingesting live data over a suitable period. If you need assistance calculating storage requirements or determining the best storage solution for your setup, feel free to contact our support team.

No Usernames in SonicWall Reports? Here’s Why and How to Fix It

If your Cyfin reports and dashboards are only displaying IP addresses instead of usernames, it indicates that SonicWall is not authenticating users.

Why Are There No Usernames?

Cyfin relies on SonicWall to log usernames. When SonicWall does not authenticate users, only IP addresses are captured in the log data. As a result, Cyfin will show the IP address in place of a username.

How to Enable User Authentication in SonicWall

To report on actual usernames, user authentication must be enabled on your SonicWall firewall. Here’s how to ensure usernames are included in your logs:

Configure Authentication Settings – Go to Users | Settings in your SonicWall appliance and set up an authentication method. Typically, this will be one of the following:
- LDAP + Local Users
- Active Directory Single Sign-On (SSO) using the SonicWall SSO Agent.
Force User Authentication – After configuring authentication, you need to set access rules that require users to authenticate before traffic is allowed through the firewall. For detailed instructions, refer to the SonicWall Knowledge Base article How to Force User Authentication Prior to Allowing Traffic Through the Firewall.
Verify AD SSO is Working – If you’re using Active Directory Single Sign-On, ensure it’s functioning correctly by following the test steps outlined at the end of the SonicWall guide.

By enabling authentication on your SonicWall, Cyfin will be able to log and display usernames, providing more meaningful and detailed reports.

How to Verify SonicWall is Authenticating Users

You can confirm whether SonicWall is logging usernames (independently of Cyfin) by checking SonicWall’s built-in log monitor. Follow these steps:

Step 1: Ensure SonicWall is Logging Internet Usage Events

Go to Log | Settings and expand the Log | Syslog section.
Click the Configure button next to Syslog Website Accessed events.
Ensure that the option Display Events in Log Monitor is enabled and set the display interval to 0 seconds.

Step 2: Investigate Logs for User Authentication

Navigate to Investigate | Event Logs.
Filter the logs by:
- Priority = Inform
- Category = Log
- Source IP = (enter the IP address you want to check, such as your own for testing purposes).
  This will display all web traffic for that IP address.
Click the More Details button (three lines) next to any event to view additional details.

Step 3: Check the Username Field

In the event details, look for the Username field. If this field is blank, it means that the IP address in question is not being authenticated for web traffic.

Additional Support

If you need further help with authentication issues, it’s best to contact SonicWall support. When troubleshooting, show them the issue using the SonicWall log monitor as described above.

Once SonicWall is logging authenticated users, Cyfin Reporter will be able to match usernames with their corresponding Active Directory objects. This allows you to take advantage of features like reporting on Departments and Security Groups. For more information, see our article on SonicWall Reporting on Users, Departments, and AD Security Groups.

Learn More