Full K-Shield Workflow

Use this guide when you need the complete K-Shield workflow shown in the current screenshots: dashboard review, VM-level scanning, managed-node review, monitoring, compliance validation, and report downloads. New users should follow the sections in order: start with Node-Level Dashboard, review VM-Level Dashboard, complete any VM scan or schedule review, then open the managed-node tabs — FIPS Compliance, Scan's Overview, History, Monitoring, and Audit stream.

1. Node-Level Dashboard

When to Use:

Use this first when reviewing the node-level dashboard shown below.

Purpose:

Review the node-level dashboard cards, charts, node table, and top vulnerabilities.

Steps:

1. Open K-Shield -> Dashboard.

2. Select Node level.

3. Review category score cards across the top.

4. Review fleet summary cards.

5. Review the trend chart, risk distribution, security nodes table, and top vulnerabilities.

6. Select a managed node if you need details.

K-Shield node-level dashboard.

What this screenshot shows:

• Managed nodes in the left panel.

• Node level selected on the dashboard.

• Node level and VM level tabs at the top of the dashboard.

• Category cards for operating systems, databases, web servers and apps, network devices, virtualization, and storage.

• Fleet cards for Total Nodes, Compliance Score, Risk Level, Total Findings, Scanned, and Not Scanned.

• Compliance Trend Chart and Risk Distribution.

• Security Nodes and Top Vulnerabilities tables.

What you can do from this screen:

• Identify scanned and not-scanned node counts.

• Compare node compliance scores.

• Review CAT I, CAT II, and CAT III distribution.

• Open a managed node from the table or left panel.

• Use the selected managed-node card in the left panel to confirm which node will open.

• Use top vulnerabilities to find repeated issues across nodes.

• As a new user, start here before opening managed-node details.

Expected Outcome:

• The node-level dashboard information is visible and readable.

• Managed nodes are available for selection.

If this fails:

1. Refresh the dashboard.

2. Confirm managed nodes appear in the left panel.

3. Confirm the Node level tab is selected.

2. VM-Level Dashboard

When to Use:

Use this when reviewing the VM-level dashboard shown below.

Purpose:

Review the VM list, VM status, K-Shield responding status, compliance score, and last scan data.

Steps:

1. Open K-Shield -> Dashboard.

2. Select VM level.

3. Open VM List.

4. Review VM status and K-Shield responding status.

5. Check compliance score and last scan details.

6. Select one or more eligible VMs when a scan is required.

K-Shield VM-level dashboard.

What this screenshot shows:

• VM level selected on the dashboard.

• VM List, Batch History, and Schedule History tabs.

• VM scan eligibility table.

• VM name, IP, VM status, node IP, K-Shield responding state, compliance score, and last scan.

• Eligibility filter dropdown, Schedule scan button, Run VM scans button, and refresh icon.

What you can do from this screen:

• Find VMs shown in the eligibility table.

• Confirm whether K-Shield is responding for each VM.

• Use row checkboxes to select VMs before running or scheduling scans.

• Run immediate VM scans.

• Schedule VM scans.

• Use the refresh icon to reload VM eligibility.

• Open batch and schedule history.

• As a new user, review this after the node-level dashboard so both dashboard scopes are covered.

Expected Outcome:

• VM-level dashboard information is visible and readable.

• VM scan actions are visible on the page.

If this fails:

1. Refresh the VM list.

2. Confirm the VM level tab is selected.

3. Confirm VM rows are visible.

3. Run VM Scans

When to Use:

Use this when selecting VMs from the VM list shown below.

Purpose:

Select VMs and open the scan action shown on the VM-level dashboard.

Important

K-Shield enablement runs on the target VM during a scan, so confirm these reachability and account prerequisites first.

Ubuntu / Linux

• The VM must be reachable over SSH on port 22.

• Use root or a user with sudo privileges.

• Package repositories must be reachable from the VM; Ubuntu/Debian systems require access to apt repositories.

• systemd must be available, because the installer enables and starts K-Shield with systemctl.

• Sufficient free space must be available on / and /tmp for package installation.

Windows

• The VM must be reachable from the management node by at least one supported method: WinRM on port 5985, or SSH on port 22 if Windows OpenSSH access is already enabled.

• Use an Administrator-level account.

• The VM must be able to download the installer from the configured installer source; if the installer is hosted externally, outbound HTTP/HTTPS access may be required.

• Windows Firewall and network rules must allow the selected management path (WinRM and/or SSH) and allow the service to be installed and started.

Steps:

1. Open K-Shield -> Dashboard -> VM level.

2. Open VM List.

3. Select one or more VMs.

4. Click Run VM scans.

5. Select the correct security profile for each VM.

6. Choose Run now when immediate validation is required.

VM scan selection from the VM-level dashboard.

What this screenshot shows:

• Eligible VM rows selected for scanning.

• Row checkboxes showing selected VMs.

• VM status and K-Shield responding status.

• Run VM scans action available.

• Schedule scan action and refresh icon beside the scan action.

• Compliance score and last scan information.

What you can do from this screen:

• Select VMs for a batch scan.

• Filter to eligible VMs.

• Open the VM scan dialog.

• Use the refresh icon if eligibility or scan state looks stale.

• Refresh scan eligibility.

Expected Outcome:

• Selected VM rows are clear.

• The Run VM scans action is available.

If this fails:

1. Confirm at least one VM row is selected.

2. Refresh the VM list.

3. Confirm the Run VM scans button is visible.

4. Start or Schedule VM Scan

When to Use:

Use this after the scan dialog shown below opens.

Purpose:

Review selected VMs, profile selectors, and run or schedule controls.

Steps:

1. Confirm the selected VMs in the dialog.

2. Select the correct security profile for each VM.

3. Choose Run now for immediate execution.

4. Choose Schedule for future execution.

5. If scheduling, select the date and time.

6. Click the visible scan or schedule action.

Start VM Scans dialog.

What this screenshot shows:

• Selected VMs.

• Selected VM chips at the top of the dialog.

• Per-VM security profile selectors.

• Execution controls for Run now and Schedule.

• Date and time fields for scheduled execution.

• Close icon in the upper-right of the dialog.

• Final Schedule Scan action.

What you can do from this screen:

• Assign different profiles to different VMs.

• Run the selected scans immediately.

• Schedule scans for the selected date and time.

• Use the close icon or Cancel if the selected VMs or profiles are wrong.

• Cancel if the wrong VMs or profiles were selected.

Expected Outcome:

• Selected VMs and profile selectors are visible.

• Run and schedule controls are visible.

If this fails:

1. Reopen the dialog.

2. Confirm selected VMs are listed.

3. Confirm profile selectors are visible.

4. Confirm date and time fields are visible when Schedule is selected.

5. Schedule VM Scan Selection

When to Use:

Use this when the schedule selection screen shown below is open.

Purpose:

Review the schedule selection controls for the selected VMs.

Steps:

1. Select eligible VMs from VM List.

2. Click Schedule scan.

3. Confirm selected VMs.

4. Select profiles.

5. Select date and time.

6. Save the schedule.

VM scan schedule selection.

What this screenshot shows:

• Selected VM scan schedule flow.

• Selected VM chips and security profile selectors.

• Security profile selection.

• Schedule controls for date and time.

• Cancel and final schedule action.

What you can do from this screen:

• Prepare a scheduled VM scan.

• Review schedule controls.

• Confirm the selected baseline profile before saving.

• Cancel before saving if the selected VM or time is incorrect.

Expected Outcome:

• Schedule controls are visible.

• Selected VM scan details are visible.

If this fails:

1. Confirm at least one VM is selected.

2. Confirm the selected time is valid.

3. Refresh and retry.

6. VM Batch History

When to Use:

Use this when viewing the VM batch history screen shown below.

Purpose:

Review VM scan batch records.

Steps:

1. Open K-Shield -> Dashboard -> VM level.

2. Open Batch History.

3. Review scan batch status.

4. Confirm included VMs.

5. Check start and completion times.

6. Review rows that need attention.

VM batch history.

What this screenshot shows:

• VM scan batch history.

• Batch execution records.

• Status and timing information.

• Batch history tab selected in the VM-level view.

What you can do from this screen:

• Confirm that a VM scan batch started.

• Review which VMs were included.

• Review visible status badges.

• Identify rows with incomplete or non-success status.

• Review batch status information.

Expected Outcome:

• VM batch records are visible.

• Batch status and timing information are visible.

If this fails:

1. Refresh batch history.

2. Confirm the Batch History tab is selected.

3. Confirm batch rows are visible.

7. VM Schedule History

When to Use:

Use this when viewing the VM schedule history screen shown below.

Purpose:

Review scheduled VM scan records.

Steps:

1. Open K-Shield -> Dashboard -> VM level.

2. Open Schedule History.

3. Confirm the scheduled scan appears.

4. Review schedule time and target VMs.

5. Check completed scheduled runs after execution time.

VM schedule history.

What this screenshot shows:

• Scheduled VM scan records.

• Schedule history tab.

• Scheduled or completed execution information.

• Schedule history tab selected in the VM-level view.

What you can do from this screen:

• Verify scheduled scans.

• Review past scheduled scan runs.

• Confirm scheduled scan records.

• Use visible status/timing fields to confirm the scheduled entry.

Expected Outcome:

• Schedule history records are visible.

• Schedule details are readable.

If this fails:

1. Refresh schedule history.

2. Confirm the Schedule History tab is selected.

3. Confirm schedule rows are visible.

8. Dashboard Help

When to Use:

Use this when a user needs help interpreting K-Shield dashboard fields.

Purpose:

Explain the node-level and VM-level dashboard areas without leaving the K-Shield workflow.

Steps:

1. Open K-Shield -> Dashboard.

2. Click the help icon.

3. Review dashboard guidance.

4. Return to the dashboard.

K-Shield dashboard help.

What this screenshot shows:

• Dashboard help content.

• Guidance for node-level and VM-level dashboard review.

• Help icon that opens the dashboard guidance.

What you can do from this screen:

• Confirm what dashboard fields mean.

• Help a new user understand the workflow.

• Use the help icon when a dashboard field is unfamiliar.

• Return to dashboard review after reading guidance.

Expected Outcome:

• Dashboard help content is visible.

If this fails:

1. Close and reopen the help panel.

2. Refresh the page.

3. Confirm the help icon is visible.

Managed Node Tabs

Selecting a managed node from the Node level dashboard opens a tabbed page: FIPS Compliance, Scan's Overview, History, Monitoring, and Audit stream. Start Security Scan is available from every tab. The sections below follow the tab order shown in the UI: FIPS Compliance, Scan's Overview, History, Monitoring, and Audit stream. The Audit stream tab is optional — use it only if you forward this node’s audit logs to a SIEM.

Important

A new managed node has no data until a scan runs. Run a security scan first (see 12. Start Security Scan below, or the 5-10 minute path in K-Shield Quick Tasks); the Scan's Overview, FIPS Compliance, and History tabs populate from scan results. A healthy node typically shows System Status = COMPLIANT, CAT I Issues = 0, a FIPS status of PASS, and Rootkit Hunter CLEAN.

Terms used in this section:

• CAT I / CAT II / CAT III: STIG severity categories — CAT I is the most severe (fix first), CAT III the least.

• STIG: Security Technical Implementation Guide — the hardening baseline the node is scanned against.

• FIPS 140-3: cryptographic-module standard; the FIPS Compliance tab scores the node against this profile.

• XCCDF profile ID: the exact machine-readable ID of the scanned compliance profile.

• Nmap: the network port scanner behind the Monitoring port results.

• Rootkit Hunter (rkhunter): the rootkit / local-threat scanner shown under Monitoring.

• CVSS / CWE ID: the vulnerability severity score and weakness classifier shown per finding.

• SIEM: Security Information and Event Management system; the Audit stream tab forwards audit logs to it.

• mTLS: mutual TLS (both sides present certificates) — an Audit stream transport option.

For shared platform terms, see Glossary.

9. FIPS Compliance

Note

If this tab (and Scan's Overview / History) is empty, no scan has run yet — run one first (see 12. Start Security Scan).

When to Use:

Use this when validating the node against the FIPS 140-3 security profile on the FIPS Compliance tab.

Purpose:

Review the FIPS score, cryptographic validation, scan outcome, severity breakdown, and findings.

Steps:

1. Open the FIPS Compliance tab.

2. Review the score gauge and STATUS.

3. Review the PASSED, FAILED, NOT APPLICABLE, COULD NOT EVALUATE, and LAST SCAN cards.

4. Review FIPS 140-3 Cryptographic Validation.

5. Review Scan Outcome and Severity Breakdown.

6. Open Findings and filter by Passed / Failed / Not applicable and by severity.

7. Review each rule and its rule ID.

What this screenshot shows:

• Score gauge with percentage and STATUS (for example GOOD).

• Cards: PROFILE (FIPS 140-3), PASSED, FAILED, NOT APPLICABLE, COULD NOT EVALUATE, and LAST SCAN.

• FIPS 140-3 Cryptographic Validation card: FIPSMode (active, kernel enforced), ComplianceStandard (FIPS 140-3), and CrytoModuleUsed (FIPS-validated modules).

• Scan Outcome donut (passed vs failed findings) and Severity Breakdown donut (high / medium / low / other).

• Findings and Compliance history sub-tabs.

• Findings table with Severity, Rule, and Rule ID, plus passed / failed / not-applicable filters, a severity filter, and an export control.

What you can do from this screen:

• Read the FIPS compliance percentage and status at a glance.

• Confirm FIPS mode and cryptographic-module validation.

• Review passed / failed counts and the severity breakdown.

• Filter findings and export the list.

Expected Outcome:

• The gauge, cards, donuts, and findings table are visible for the node.

If this fails:

1. Refresh the compliance tab.

2. Confirm the FIPS Compliance tab is selected.

3. Confirm the findings table is visible.

10. Compliance history

When to Use:

Use this when comparing FIPS compliance results across scans.

Purpose:

Review prior FIPS compliance runs for the node.

Steps:

1. Open the FIPS Compliance tab.

2. Open the Compliance history sub-tab.

3. Review the history rows.

FIPS Compliance history.

What this screenshot shows:

• Compliance history table with Profile, Status, Grade, Score, Passed, Failed, Scan time, and severity split per row.

What you can do from this screen:

• Compare prior FIPS compliance results.

• Track score and grade trend over time.

Expected Outcome:

• Compliance history rows are visible.

If this fails:

1. Refresh the compliance tab.

2. Confirm the Compliance history sub-tab is selected.

11. Scan’s Overview

When to Use:

Use this when reviewing a managed node’s security posture on the Scan's Overview tab shown below.

Purpose:

Review the node’s compliance and CAT issue cards, compliance trend, security score panel, and the vulnerabilities table.

Note

The Vulnerabilities here are detected misconfigurations and CVEs from the scan — distinct from the FIPS Compliance tab’s Findings, which are pass/fail results of FIPS 140-3 hardening rules.

Steps:

1. Open K-Shield -> Dashboard -> Node level.

2. Select a managed node from the left panel or the Security Nodes table.

3. Open Scan's Overview.

4. Review the Compliance Score, System Status, and CAT I/II/III Issues cards.

5. Review the Compliance Trend chart and the Security Score Panel.

6. Review the Vulnerabilities table and filter by severity when triaging.

7. Click Recommend on a finding to open its remediation dialog.

Managed-node Scan’s Overview.

What this screenshot shows:

• Managed-node breadcrumb and the left Managed Nodes panel with per-node FIPS compliance.

• Tab bar: FIPS Compliance, Scan's Overview, History, Monitoring, and Audit stream.

• Start Security Scan action (available from every node tab).

• Cards for Compliance Score, System Status, CAT I Issues, CAT II Issues, and CAT III Issues.

• Compliance Trend chart for score movement across scan dates.

• Security Score Panel with profile, security posture (a qualitative rating such as MINIMAL — read it alongside the compliance score and CAT counts, not as a pass/fail), zero-day vulnerabilities, remediation pending, top vulnerability category, last scan status, and last scan completed.

• Vulnerabilities table with internal ID, title, type, external ID, CWE ID, severity, CVSS, detected-on date, and a Recommend action per row.

• Severity filter for the vulnerability rows.

What you can do from this screen:

• Confirm the latest compliance score, system status, and CAT issue counts.

• Review the security profile and posture in the score panel.

• Filter vulnerabilities by severity and open Recommend for a finding’s remediation dialog.

• Start a new security scan.

• Move to the FIPS Compliance, History, Monitoring, or Audit stream tabs.

Clicking Recommend on a vulnerability opens its remediation dialog:

Remediation recommendation for a selected vulnerability.

The recommendation dialog shows:

• A WARNING describing the risk and impact of the finding.

• REMEDIATION STEPS with a Copy action, including a note when automated remediation is not provided.

• A numbered RECOMMENDATION with the manual steps to remediate the finding safely.

Expected Outcome:

• The selected node’s overview cards, trend chart, score panel, and vulnerability rows are visible.

If this fails:

1. Refresh the managed-node page.

2. Confirm the selected node appears in the breadcrumb.

3. Confirm the Scan's Overview tab is selected.

12. Start Security Scan

When to Use:

Use this when you need a fresh compliance scan of the selected managed node.

Purpose:

Choose a validated STIG profile and start the scan.

Tip

Pick the profile that matches the node’s role and your security team’s approved baseline. The profile names indicate their scope — for example, Hypervisor Security Configuration for hypervisor / compute hosts, Network Security Configuration or Storage Security Configuration for network or storage roles, and Karios Debian Security Baseline as the general OS baseline. Use the same profile on re-scans so results stay comparable.

Steps:

1. Click Start Security Scan.

2. Choose a validated STIG profile from the list.

3. Confirm the value shown under Selected Profile.

4. Click Start Security Scan in the dialog.

5. Optionally close the window — the scan continues in the background.

Choose a validated STIG profile for the scan.

The scan runs in the background after it starts.

What this screenshot shows:

• Profile dialog titled Choose from validated STIG profiles ready for compliance scanning.

• Selectable profiles: Karios Debian Security Baseline, Hypervisor Security Configuration, Network Security Configuration, and Storage Security Configuration.

• Selected Profile summary and the Cancel / Start Security Scan actions.

• Progress modal with a status (for example Connecting...), a progress bar and percentage, and the note that you can close the window while the scan continues in the background.

What you can do from this screen:

• Select the approved security profile for the node.

• Start the scan immediately.

• Close the window and let the scan finish in the background.

Expected Outcome:

• The scan is submitted and progress is shown.

• Results populate Scan's Overview and History after completion.

If this fails:

1. Reopen the dialog.

2. Confirm a profile is selected.

3. Refresh the page and retry.

13. Security Scan History

When to Use:

Use this when reviewing past scans and downloading reports on the History tab.

Purpose:

Review previous scan details, recent changes, and download HTML/PDF reports.

Steps:

1. Open the History tab.

2. Review the Compliance Score, Compliance, and Vulnerabilities cards.

3. Review Previous Scan Details, Recent Changes, and Compliance Gap Analysis.

4. In the Scan History table, find the scan row to review.

5. In the Reports column, click the HTML report icon to download the HTML report.

6. Click the PDF report icon to download the PDF report.

7. Open the downloaded report from your browser downloads to review it outside K-Shield.

Security scan history with downloadable reports.

What this screenshot shows:

• Cards for Compliance Score, Compliance, and Vulnerabilities.

• Previous Scan Details (scan time, initiator, top risk category, common vulnerability type).

• Recent Changes (new vulnerabilities, vulnerabilities closed) and Compliance Gap Analysis (improving / declining controls).

• Scan History table with scan ID, date and target, status, profile, compliance score, vulnerabilities count, and a Reports column with HTML and PDF download icons.

• Refresh History and Start Security Scan actions.

What you can do from this screen:

• Review the previous scan and what changed since the last run.

• Download the HTML and PDF reports for any scan row.

• Refresh history after a new scan completes.

Expected Outcome:

• History cards, scan rows, and the report icons in the Reports column are visible.

If this fails:

1. Refresh history.

2. Confirm the History tab is selected.

3. Confirm the Reports column contains the report icons.

14. Monitoring

When to Use:

Use this when reviewing node network exposure and rootkit status on the Monitoring tab.

Purpose:

Review the Nmap score, port-scan summary, open ports, and supporting monitoring cards.

Steps:

1. Open the Monitoring tab.

2. Review the NMAP Score, Latest Port Scan Summary, Unexpected Ports, Rkhunter Status, and Rkhunter Warnings cards.

3. Review Nmap Scan Details and the Port Security Risk Timeline.

4. Open Open Ports and review each port, protocol, service, and impact.

5. Click View details on a port row when you need the full guidance.

Monitoring overview with Nmap score and port summary.

Open Ports table with per-port impact and details.

What this screenshot shows:

• Cards: NMAP Score (with risk band), Latest Port Scan Summary (ports count), Unexpected Ports, Rkhunter Status (for example CLEAN), and Rkhunter Warnings.

• Nmap Scan Details (hostname, scan ID, scan time, total ports scanned).

• Port Security Risk Timeline chart.

• Open Ports and Unexpected Ports sub-tabs.

• Open Ports table with port, protocol, service, impact text, and View details; rows are paginated.

What you can do from this screen:

• Review the node’s network exposure and Nmap score.

• Open per-port details and impact guidance.

• Switch to Unexpected Ports for flagged ports.

Expected Outcome:

• Monitoring cards, Nmap details, and the open-ports table are visible.

If this fails:

1. Refresh the monitoring tab.

2. Confirm the Monitoring tab is selected.

3. Confirm the monitoring cards are visible.

15. Unexpected Ports

When to Use:

Use this when triaging unexpected open ports on the Monitoring tab.

Purpose:

Review ports flagged as unexpected and act on them.

Steps:

1. Open the Monitoring tab.

2. Select Unexpected Ports.

3. Review each port, protocol, service, and status.

4. Click View details for impact and remediation guidance.

Unexpected open ports flagged for review.

What this screenshot shows:

• Unexpected Ports sub-tab table with port, protocol, service, version, status (severity), and View details.

• A banner stating how many unexpected open ports were detected.

What you can do from this screen:

• Review unexpected ports and their severity.

• Open per-port details and act on flagged ports.

Expected Outcome:

• Unexpected-port rows are visible.

If this fails:

1. Refresh the monitoring tab.

2. Confirm Unexpected Ports is selected.

3. Confirm unexpected-port rows are visible.

16. Rootkit Hunter Scan

When to Use:

Use this when reviewing rootkit scan results for the node.

Purpose:

Confirm rootkit status and review the rootkit scan history.

Steps:

1. Open the Monitoring tab.

2. Scroll to Rootkit Hunter Scan.

3. Review System Status and the scan summary cards.

4. Review the Scan History table and download reports when needed.

Rootkit Hunter Scan summary and history.

What this screenshot shows:

• System Status (for example SECURE / PASSED).

• Summary cards: Files Verified, Suspect Files, Rootkits Checked, Possible Rootkits, Checks Passed, and Checks Failed.

• Last scan completed time and duration.

• Scan History table with scan ID, scan time, warnings, status (for example Clean), reports, and View details.

What you can do from this screen:

• Confirm the node’s rootkit status.

• Review the rootkit scan history and download reports.

Expected Outcome:

• Rootkit status and scan history are visible.

If this fails:

1. Refresh the monitoring tab.

2. Confirm the Monitoring tab is selected.

3. Confirm the Rootkit Hunter fields are visible.

17. Audit stream

Note

The Audit stream tab is optional. Configure it only when this node’s audit logs must be forwarded to a SIEM. Scanning, monitoring, and compliance all work without it.

When to Use:

Use the Audit stream tab to forward this node’s audit logs to a SIEM and to monitor that forwarding.

Purpose:

Enable forwarding, set the SIEM endpoint, review the runtime and transport configuration, and watch live delivery status and raw audit lines.

Steps:

1. Open the Audit stream tab.

2. Turn on the Audit stream toggle, enter the SIEM Endpoint URL, and click Save changes (Reset discards unsaved changes; Refresh reloads config and status).

3. Confirm the status chips (for example Healthy and Stream active).

4. Review Runtime Settings, Transport, Stream Status, and HTTP Metrics.

5. Use the SIEM Delivery Status and Raw Audit Lines sub-tabs to inspect activity.

Audit Stream Configuration

Audit stream disabled, before a SIEM endpoint is set.

Audit stream enabled and forwarding to the configured SIEM endpoint.

• Audit stream: enables or disables forwarding of audit log events from this node to the configured SIEM endpoint.

• SIEM Endpoint: the destination URL where audit events from this node are sent.

• Save changes / Reset / Refresh: apply the setting and endpoint; discard unsaved changes; reload the latest config, status, and activity.

• Runtime Settings — read-only node-side settings:

  • Log path: the audit log file currently being monitored on the node.

  • Queue size: the maximum number of audit events that can be buffered before sending.

  • Workers: how many background workers are forwarding audit events.

  • Reopen interval: how often the service rechecks and reopens the audit log file if needed.

  • Read from start: whether the stream reads the file from the beginning or only new entries.

• Transport — current delivery configuration and security settings:

  • SIEM endpoint: the currently active endpoint configured on the node.

  • Endpoint configured: whether a SIEM destination is configured on the node.

  • Auth header: whether a custom authentication header is configured for outbound requests.

  • mTLS: whether mutual TLS is enabled for SIEM delivery.

  • TLS skip verify: whether TLS certificate verification is disabled for the endpoint.

Stream Status and HTTP Metrics

Live stream counters and HTTP delivery metrics.

• Stream Status — live counters from the audit stream worker:

  • Queue depth: events currently buffered versus total queue capacity.

  • Lines read: total audit log lines read from the node.

  • Lines dropped: audit lines dropped before delivery, usually due to queue pressure.

  • Send success / Send failures: total events successfully forwarded / failed forwarding attempts.

  • Last read / Last send failure: when the most recent line was read / the most recent failure occurred.

• HTTP Metrics — delivery-layer connection usage and latency:

  • Connections reused / Fresh connections: sends that reused an existing HTTP connection / opened a new one.

  • Send latency (last): how long the most recent send took.

  • Queue depth, Send success, and Send failures here mirror Stream Status from the delivery layer’s perspective.

SIEM Delivery Status

SIEM delivery status (stream health, not raw logs).

The SIEM Delivery Status sub-tab lists recent activity — reads, sends, failures, and queue events. Columns: Time, Status (informational / successful / warning / failed), Activity (what the worker did, such as reading lines or forwarding to SIEM), Endpoint, Latency, Queue, and Details (extra context, including failure details when present).

Raw Audit Lines

Latest tailed audit.log entries.

The Raw Audit Lines sub-tab shows the latest audit.log entries read from the node (not SIEM delivery events). Columns: Time and Raw line — the exact audit record, for example type=USER_END, type=CRED_DISP, or type=USER_START.

Expected Outcome:

• Forwarding is enabled, the status shows Healthy / Stream active, and SIEM Delivery Status shows Success rows.

If this fails:

1. Confirm the SIEM Endpoint URL is valid and reachable from the node; click Save changes and Refresh.

2. Check Stream Status / HTTP Metrics for non-zero Lines dropped or Send failures.

3. Confirm there is recent activity in audit.log and the stream is running.

18. Troubleshooting

Use the per-section If this fails notes first. For cross-cutting issues, start here:

Symptom	First actions
A tab is empty / no data	No scan has run yet — run a scan (see 12. Start Security Scan) and Refresh.
Scan does not start or fails	Confirm your role has scan permission and the node is online in the left panel; Refresh and retry once. For VM scans, confirm prerequisites — Ubuntu Ubuntu VM Scan user data, Windows QEMU Guest Agent running.
Node not listed / not managed	Confirm the node is onboarded and discovered, Node level is selected, then Refresh.
Score or findings not updating	Refresh, re-run the scan, and compare by scan ID and time in Security Scan History.
Reports will not download	Confirm the scan is COMPLETED, use the HTML/PDF icons in the Reports column, and check browser downloads / pop-up blocking.
Audit stream not forwarding	Confirm Audit stream is enabled and the SIEM Endpoint is set and reachable; check Stream Status / HTTP Metrics for Send failures and SIEM Delivery Status for failed rows.
Unexpected ports or rootkit warnings	Review in Monitoring (Unexpected Ports / Rootkit Hunter Scan), open View details, remediate, and re-scan.

Escalate when a controlled retry does not resolve the issue. Include the node name, scan ID, timestamp, severity summary, and impact scope, and contact support@karios.com for Karios platform escalation.

---

→ Next: K-Trace