WASViking Docs
⌘K
Getting Started

Set up Infrastructure Defense

Enroll your first servers step by step. Create an activation key, install the Sentinel Host agent on Windows, Linux or macOS (including MSI mass deployment), meet your fleet on the Assets screen, and set the policies that govern assessment and patching.

This guide takes you from an empty module to a scored fleet: by the end you will have agents reporting from your servers, every host carrying a Viking Exposure Score with its factors visible, and the rules of engagement (what gets assessed, who approves changes, when changes are allowed) written down as policies. Nothing here requires opening an inbound port or touching a firewall rule: the agent always connects out, over mutual TLS.

Before you start

Infrastructure Defense is an add-on module enabled per organization by your WASViking contact or partner. Once it is on, the Infrastructure Defense section appears in the portal sidebar. Enrolling and managing agents needs the Manage permission on the module; approving patch jobs needs the dedicated Remediate permission, so you can keep those two responsibilities in different hands from day one.

Step 1: choose how you will enroll

Open Infrastructure Defense → Sentinel Hosts. The screen offers the two onboarding paths side by side:

  • Enroll a single server mints a one-time token for one machine. Best when you are trying the module on one or two hosts.
  • Use an activation key creates one reusable credential that enrolls a whole fleet: each machine registers itself under its own hostname and certificate identity. Best for rollouts and automation, and the path this guide follows.

Step 2: create an activation key

Open the Activation keys tab, give the key a title your team will recognize ("Production servers", "Data center onboarding"), optionally cap how many agents it may enroll and when it expires, pick the policy its hosts start under, and generate it. You can disable, edit or delete a key at any time without touching the agents already enrolled, and the counter next to each key shows how much of your plan's host allowance it has consumed.

Activation keys tab with a reusable key, its agent cap, policy and status

Step 3: install the agent

Click Install agent next to the key. The install page carries the key inside every command, so installation is one download and one line on the server: the agent trades the key for its own certificate identity and starts the service. Pick the platform:

  • Windows (x86_64 or ARM64): unpack the zip and run the executable's own install command from an elevated PowerShell. It copies itself to Program Files, registers the host and starts the Windows service. No scripts, so the execution policy never gets in the way.
  • Linux (x86_64 or ARM64): unpack the tar.gz and run the install command as root; the agent registers and starts under systemd.
  • macOS (Intel or Apple Silicon): same one-command flow, started under launchd.

For Windows fleets there is a second, fully unattended path on the same page: the MSI package. Push it through group policy or the device management tool you already run, with the activation key passed as an installer property, and every server enrolls itself as SYSTEM with no interaction. The exact msiexec line is shown ready to copy.

Install page with the Windows package selected, installation steps and the MSI fleet deployment block

After enrollment, agents keep themselves current: when a new agent version ships, the console offers a one-click update per agent or for every selected agent at once.

Step 4: meet your fleet

Back on Sentinel Hosts → Agents, every enrolled machine appears right away with its operating system, IP, agent version, policy and status. Windows Server and Windows 10/11, Ubuntu, Debian, the RHEL family and macOS all sit in the same table with their own icons, so a mixed fleet stays readable at a glance. From the row menu you can run an inventory on demand, request the agent's logs, restart it, or uninstall it remotely; tags let you slice the fleet the way your team thinks about it ("web servers", "payment zone", "staging").

Agents tab listing macOS, Ubuntu, Windows and Debian hosts with status, version and policy

Within a few minutes of its first inventory each host also appears on the Assets screen, and its first assessment follows: packages correlated against published vulnerabilities, missing security updates, configuration checks, and the score.

Step 5: read the score, then tell the platform what the host is

Open any host on the Assets screen. The Asset Summary shows the Viking Exposure Score with every factor and its points listed next to it, so the number is never a mystery: worst open vulnerability, exploitation evidence, exposure, pending updates, end of life state.

Two inputs here are yours to set, and both move the score: under Edit business context, set the environment (production raises the stakes, staging lowers them) and the criticality of the asset. Internet exposure you can leave on automatic: the platform's own attack surface discovery proves it, names the evidence on the screen, and a manual choice always wins if you disagree.

Asset detail with the Viking Exposure Score and its named factors, host identity and business context

Step 6: write the rules down as policies

Open Infrastructure Defense → Policies. A policy states exactly how far the platform may go for the hosts under it: which assessments run, whether the platform may recommend and create patch jobs, whether a person must approve them (on by default), whether anything may ever deploy or reboot automatically (both off by default), and the maintenance window where changes are allowed. Assign a policy per activation key, per agent, or in bulk from the Agents tab. The default policy ships safe: assess everything, change nothing without approval.

Policies screen with the default policy: assessment scope, remediation authority and safety guardrails

Step 7: route the outcomes to your team

In Alert Destinations, enable the Infrastructure patch job event on the channels your team watches (Slack, Teams, email or webhook). A verified job announces itself with the measured numbers (score before and after, vulnerabilities closed); a failed job arrives with the reason. Decisions a person made in the portal, like rejecting a job, are deliberately never broadcast.

Step 8: run your first remediation

When the first assessment lands, open Resolve. Recommended actions group the pending security updates per host, ranked by the score reduction they are expected to deliver. Schedule one, approve it (run now, or let it wait for the maintenance window), and watch the cycle finish honestly: the agent runs pre-checks, applies the updates through the platform's native mechanism, and the job only completes when the next inventory proves which vulnerabilities closed and how far the score dropped. If a reboot is still pending, the job says so instead of declaring victory early.

What to look at next

  • Configuration and Compliance show the CIS-aligned check results and the compliance percentage per host and for the fleet.
  • Software answers inventory questions across the fleet, down to which hosts run a specific package and version.
  • Download report on the Overview exports the branded PDF: fleet posture, verified risk reduction and top risks, ready for a stakeholder who will never open the portal.

For the full picture of what the module assesses and how the score is built, see Infrastructure Defense in Capabilities.