Infrastructure Defense

Security posture for your infrastructure. The Sentinel Host agent inventories each machine, the Sentinel Probe scans the networks around them and the Sentinel Gateway carries the sites with a thin internet link, the cloud correlates vulnerabilities and misconfigurations, the Viking Exposure Score prioritizes them, and Resolve executes approved fixes with a measured risk reduction.

WASViking^® Infrastructure Defense is the security posture of the servers running your business, in one place: what you have, where it is vulnerable, which fixes matter most, and how much risk each executed fix actually removed. It works from facts a lightweight agent collects on each host and it never ends at "N vulnerabilities found"; the cycle only closes when a later inventory proves the risk dropped.

How it works

A small agent, the WASViking Sentinel Host, runs on each enrolled server and reports a security posture inventory over mutual TLS: operating system and kernel, installed packages, running services and listening ports, pending updates, and security configuration such as the firewall state and the SSH hardening options. The asset inventory also carries the machine facts an operator expects on an asset record: naming (FQDN, DNS hostname, and on Windows the NetBIOS name), IPv4 and IPv6 addresses, manufacturer and model, processor and total memory, fixed volumes with free space, and the local account names as the operating system reports them. It reads posture only; it never opens user files or content, and account names are collected without any profile data or per-user activity.

Every inventory is correlated in the WASViking cloud:

• Installed packages are matched against the OSV vulnerability database, qualified by the exact distribution release so a patched host is never flagged for another branch's bug. macOS updates come from the published security releases, and third-party Windows applications from the package manager inventory. Amazon Linux, which OSV does not cover, is matched against the vendor's own security advisories (ALAS) with the same per-package, release-qualified comparison, for Amazon Linux 2023 and 2.
• Windows hosts are assessed by OS build revision. Every security fix Microsoft shipped in a cumulative update the host has not reached is an open vulnerability, named with the KB and build that close it. The revision is the authoritative signal, so an update that is installed but still waits for a restart does not count as applied, and the pending list from the update service shows which cumulative closes what.
• Each vulnerability carries its CVSS severity, its EPSS exploitation probability, and whether it appears in the CISA Known Exploited Vulnerabilities catalog.
• Every "what changed" number is a door, never a dead end. The Command Center chips (new and fixed findings in the last 24 hours) and the status tiles on the Vulnerabilities page open the exact detections behind the count: host, package, installed and fixed versions, and the moment each one was first seen or proven closed. When a host enrolled in the same period accounts for part of the new findings, the list says so, because a first inventory reports every existing finding as new. The CSV export follows the same filter.
• Pending security updates become "missing patch" context: which open vulnerabilities a published fix would close.
• An operating system or a tracked software product past its vendor's end of support is flagged from published lifecycle data, with the date on the label, because no patch is coming for it.
• A configuration catalog aligned with CIS benchmark sections evaluates the collected settings and scores each host with a compliance percentage, with a PCI DSS mapping of the same results. Every control records the expected value next to what the host reported, so a failure explains itself. The catalog covers credential protection and lateral movement on Windows (SMBv1, Remote Desktop Network Level Authentication, LSA protection, WDigest, LAPS, LLMNR, SMB signing, NTLM level, UAC, WinRM, the advanced audit policy and Microsoft Defender), kernel and access hardening on Linux (SELinux or AppArmor, ASLR, network kernel parameters, auditd, persistent logging, time synchronization, the effective sshd configuration, sudo, local accounts, system file permissions, repository signatures), and the login, root account, stealth mode and security data updates on macOS. Platform posture is collected alongside: disk encryption, Secure Boot and TPM state on Windows, System Integrity Protection, Gatekeeper and MDM enrollment on macOS. The agent reports facts only; a fact an older agent does not report is not applicable, never a failure.
• Each host policy selects the profile its hosts are held to: the WASViking baseline, or CIS Level 1 with the stricter thresholds and the additional Level 1 controls. Thresholds (password length, inactivity lock, lockout) can be tuned per policy and individual checks switched off. An approver can accept the risk of a failing control for a stated reason until a date: the control then counts as passed with exception, stays visible as an accepted risk, and returns to the open list when the exception expires. Open critical and high misconfigurations add a bounded factor to the Viking Exposure Score.
• A few findings carry a hardening action the operator can send to the host with the Remediate permission: disable SMBv1, require Network Level Authentication, turn off LLMNR, apply the kernel network hardening. The agent applies the documented change, reports a fresh inventory, and the finding closes on that evidence.
• The platform's own attack surface discovery proves internet exposure: when a discovered public asset resolves to an address assigned to the host, the exposure flag lights with the proof named, and a manual decision by your team always wins over the automation. Edge telemetry adds an active attack factor when blocked attack-grade traffic hit a hostname the server serves in the last seven days; the factor decays on its own when the traffic stops.
• The same correlation runs the other way. Every internet-facing asset you own in the Attack Surface is matched against your enrolled hosts and labeled with a management state: fully managed, partially managed, unmanaged or unknown. The Command Center says in one sentence how many externally exposed assets are not protected yet, the Coverage tab lists them with the next step for each (install the agent, add probe credentials, link the asset to the host behind a CDN or WAF), and the asset inventory shows the same verdict from the other side. Assets still waiting for triage in Discovery are never counted as unprotected. The step by step is in Bring your internet-facing assets under management.

The network view: Sentinel Probes

The agent gives you the inside of every machine you can install it on. A Sentinel Probe gives you the rest of the network. It is a virtual scanner appliance: one lightweight program on a single machine in a segment discovers every reachable device on the networks you authorize, identifies the services and versions they expose, and reports them to the same cloud for correlation and the same Viking Exposure Score. Nothing is installed on the devices it scans, and like the agent it only connects outward over mutual TLS.

This is what covers the things that will never run an agent, such as a managed switch, a printer, a database appliance or a payment terminal, and it is how the module produces the internal vulnerability scan PCI DSS asks for. The networks you declare are scanned on a cadence you set, each run is kept as dated evidence (requirement 11.3.1), an authenticated pass over SSH or WinRM looks past the surface where a system accepts credentials (requirement 11.3.1.2), and a one-click Scan now files an off-cycle run after a change (requirement 11.3.1.3). A device the probe finds that has no agent appears in your inventory as unmanaged, so you always know what you manage and what merely exists on the network. The Sentinel Probes setup guide walks through installing one, authorizing its networks and reading the results.

The site view: Sentinel Gateways

The agent needs the cloud, and a maintenance window needs the vendor's content. On a remote site with a thin link, a strict egress policy or a few hundred servers pulling the same cumulative update, the internet link is the constraint. A Sentinel Gateway is one appliance on Ubuntu Server inside the site that removes it. Agents with no route out dial the gateway and it relays them to the cloud by server name without ever opening the channel, so the mutual TLS between the agent and the cloud stays end to end. Agent releases are downloaded once and served to every host from a verified store. When a Resolve job is approved, the gateway stages its content before the window: Windows cumulative updates, third-party installers from the public package manifests, macOS packages and the installers you upload yourself, each verified against the vendor's signature and trusted roots on the gateway and again on the host. The Linux hosts of the site run apt and dnf through it, so a package travels the internet once. Bandwidth windows by schedule keep business hours untouched, and a branch gateway can sit behind a data center gateway when the branch has no internet path of its own.

Sites group your networks by address, hosts fall into them automatically and dial the gateways of their site in priority order, and the portal shows what every gateway saved: bandwidth, patch files served, packages served from the cache, cache hit rate, with the same thirty day totals on your account profile and in the Infrastructure Defense PDF report. The Sentinel Gateways setup guide covers installing one, switching on its roles, assigning sites, shaping bandwidth, uploading installers and nesting a branch.

The Viking Exposure Score

Each host gets a Viking Exposure Score from 0 to 100. The worst open vulnerability sets the base; exploitation evidence (KEV, EPSS), proven internet exposure, active attack traffic seen at the edge, end of life state, business criticality, and environment adjust it. The score is never a black box: every screen shows the exact factors and points behind the number, so "why is this critical" always has a concrete answer.

Resolve: remediation with proof

WASViking Resolve turns the priorities into work under your control:

1. Recommended actions group the pending security updates of each host, ranked by the score reduction they are expected to deliver.
2. Scheduling an action freezes it as a job with the exact package list, so the approver signs off on a concrete change. Open Review and untick the updates you want to leave for later: the job only touches what stays ticked, and the vulnerabilities closed and the expected score are recomputed for that selection. Updates left out stay recommended for the next job.
3. A person with the Remediate permission approves the job, optionally inside a maintenance window defined by the host policy. Automatic deployment and automatic reboot are off by default.
4. The agent runs pre-checks, applies the updates through the native mechanism of each platform (the system package manager on Linux, the update service on Windows, software updates on macOS), and reports the outcome per item. Third-party applications on Windows (browsers, readers, runtimes) get their own action, "Upgrade third-party applications", fed by the upgrades the winget channel offers on that host. Same freeze, approval and per-item outcome; the agent upgrades each application by its channel id and never anything the job did not name. For the applications the detection engine maps (browsers, mail clients, editors, runtimes and other common desktop software), the installed version is matched against the NVD by product and version, so the action shows the vulnerabilities the upgrade closes and the expected score, like a security update does; an application without a mapping keeps the "app currency" label, and the job keeps it on the vendor's current version. The verdict is the next inventory no longer offering the upgrade, with the findings it closed.
5. The next inventory is the verdict: the job completes only when the reassess shows which vulnerabilities closed and how far the score dropped. The before and after numbers are measured, never estimated, and when a reboot is still pending the job says so instead of declaring victory early.

One change at a time. Right before installing, the agent reads the host's own restart signals (the servicing stack, Windows Update and pending file renames on Windows; the reboot-required marker or needs-restarting on Linux). When a restart from an earlier change is still pending, the job is held instead of stacking a second change on an unfinished one: the Resolve screen shows "Held, restart pending" with the reason, the asset shows since when and after which change the restart is due, and the job resumes on its own the moment the host reports the restart done. The policy decides the exception: restart the host first (only when the approver also granted the reboot) or install anyway. On Windows, security updates and rollbacks still wait on the servicing stack and Windows Update signals, since Windows Update refuses installs while they are set. Pending file renames are a weak signal: endpoint protection and installers write them constantly and a restart does not always clear them, so they never hold a third-party application upgrade, and a job held only by them runs once the host has restarted. A "Restart host" action on the held job, on the asset and on the Agents screen clears the wait with one click, for people with the Remediate permission. An approver can also run a held job without the restart, with a stated reason kept in the job's approval record and the audit log. A job still waiting after a day raises an alert in your channels.

Every job in progress says where it is and what comes next: waiting for the agent's next check-in (with the agent's last contact), waiting for the maintenance window, held for a restart (the signal, how many checks so far, the next check and when the hold expires), running on the host or confirming the result. While a job runs, the agent reports each step as it happens: the phase (checking the host, refreshing the package sources, downloading, applying, checking the result), the package or application it is on, how many are done with a progress bar when the package manager tells the total, how long the job has been running and when the agent last reported. Windows Update reports its download and install phases; winget, apt and dnf report item by item. A job whose agent keeps reporting is never failed by the result window, however long the transaction. The Resolve table refreshes on its own while jobs are in progress, and the running step updates in place. A job approved for a host whose agent stopped checking in, for example because endpoint protection removed it, shows the agent offline since its last contact, raises one alert after a day and fails after seven days with a note that says what to do. The waiting jobs of a host whose agent is removed are cancelled at once, and a cancelled job keeps what it was waiting on.

A restart can also be scheduled as a job of its own. The Resolve screen recommends "Restart host to finish pending changes" for every host with a restart pending, and the "Hosts waiting for a restart" report lists them oldest first with the cause, the host role, the signed-in sessions and the policy that applies, with a CSV export and a "Schedule restart for all" action. A restart job follows the same contract as any change: approval under the policy, the maintenance window, and a verdict from the next inventory, which proves the restart by the boot time the host reports. The agent tells servers from workstations on its own. A server restarts after the countdown the policy sets; a workstation with a person signed in is asked first and may postpone as many times as the policy allows, after which the countdown runs without a question. A host whose restart stays pending for seven days raises its own alert, job or no job.

A change that misbehaved can be undone with the same discipline. A completed security update job on a Linux or Windows host offers "Roll back this change": a rollback job for the same packages, each one returned to the exact version it had before, with a mandatory reason, the back-out plan carried over, and the approval, window and restart rules of any other change. Linux downgrades through the package manager and never touches the kernel; Windows removes each update by its KB through Windows Update and reports the ones the platform does not allow removing; macOS has no uninstall path, and the screen says so. The reassess measures the result honestly, "VES 70 to 88, 3 of 3 packages returned, 17 vulnerabilities open again", and the returned updates stay held out of the recommendations for the days the job asked, visible on the host and released early with one click. See Roll back a change that misbehaved.

Not every finding is closed by an update. The Mitigation screen changes the host itself when a patch is not the answer: a registry value, a service state, a Linux kernel parameter, an approved script from your own library, or a software install or removal. Built-in mitigations fix the failing posture controls they name, and documented workarounds contain well-known Windows vulnerabilities that have no fix applied yet; a verified workaround marks the finding "Mitigated, no fix applied", which leaves the score like an accepted risk and opens again the moment the change is reverted. The same actions run before and after the updates of a patch job, for example a service stopped first and started again after. Every change is a job under the approval governance of the host's environment; a script or software change is never approved automatically, scripts are off until your organization turns them on and need a second person's review, and a host can refuse them in its local configuration. The agent records what each change replaced so it can be undone, the next inventory proves it held, and a change that something puts back shows as Reverted with an alert. See Mitigate a finding without a patch.

Approval governance decides who signs off, per environment. Each host carries an environment (production, staging, development or other), and the Approval Governance screen sets a rule for each one: follow the host policy, approve automatically, let one person approve (the requester included), or require a formal approval. A formal rule says how many approvals a job needs and, optionally, who may give them, by name or by role; the person who scheduled the job never counts. Every decision is recorded with who decided, when, the stated reason and the change reference, and the approval records export as CSV: the evidence a change control audit asks for. A production rule can also require the same packages to have completed in staging or development within a window before production accepts them; a job that arrives untested says so, and an approver has to waive it on purpose. Approvals that wait past the window set in the rule are cancelled, formal approvals waiting are announced to your alert channels and to the approvers by e-mail, and the requester hears the decision. When the rule allows it, an emergency approval runs the job without the quorum, with a stated reason; every approver is notified and the job stays flagged until another approver reviews it. When the rule names its approvers, the emergency path belongs to that list too. The person scheduling a change can state why it is needed and how it is undone, and a rule can refuse a change scheduled without that back-out plan; both stay in the approval record and the export. A job answers to the environment it was created in: moving a host to a less guarded environment afterwards changes nothing for jobs already waiting, and the move itself needs the Approve permission, is recorded with the before and after, and raises an alert on your channels.

Policies decide how far the platform may go on each group of hosts: what gets assessed, whether jobs need manual approval where the governance follows the policy, and when changes are allowed. Every action lands in the audit trail, and the patch job outcome can notify your Slack, Teams, email, or webhook channels.

Performance and resource protection is part of the same policy. It states how much of a host the agent may take and when it must step aside: a share of the machine's CPU (a hard cap through the systemd control group on Linux and through a job object on Windows, a scheduling priority on macOS), the inventory and check-in cadence, reduced scheduling priority for the agent and every subprocess it spawns, and a daily reduced activity window in the host's own local time. Three presets cover the usual cases: conservative for critical production, balanced for the fleet at large, performance for development and test; custom exposes every number. Beyond the static limit, the agent looks at the host before every scheduled assessment and before every patch job. A host above the policy's CPU or memory thresholds, or under critical load, is left alone: the assessment waits and looks again every ten minutes, up to the policy maximum, then runs anyway at reduced priority so coverage never lapses in silence; a patch job goes back to the cloud as deferred, is offered again a quarter of an hour later and fails visibly, with the numbers in the note, if the host never calms down inside the maximum wait. Each asset page shows what its agent reports: the profile revision it applies, how the platform enforces it, the last load sample and any work on hold. Agents from release 0.1.34 apply the profile; older agents follow its inventory cadence only.

Fleet hygiene keeps the agent list honest without anyone tidying it. The monitored hosts allowance counts assets that reported, never enrollment attempts. An installer that cannot reach the cloud stops before registering and names the product in the way; an enrollment that registered but never sent its first inventory raises one alert with the check to run and the exclusions to apply; a token never used expires; and when a machine finally reports, the earlier enrollments of the same hostname that never completed are retired on their own. The Sentinel Hosts screen flags what needs attention (never reported, token never used, duplicate hostname, silent for a week), offers a one-click removal of the incomplete enrollments of a hostname, and lets you set the housekeeping windows: how long a silent host is kept, how long a token lives unused, and how soon a missing first inventory is announced.

Reporting

The Overview screen answers the ten second question: overall infrastructure risk, the fleet numbers, and the top risks with their reasons. A branded PDF report exports the same story for stakeholders: fleet posture, verified risk reduction, top vulnerabilities, misconfigurations, and per host compliance.

Set up

Infrastructure Defense is an add-on module enabled per organization. Once it is on, open Infrastructure Defense → Sentinel Hosts in the portal. For a single server, enroll a host to get its one time credentials and run the two commands shown on the enrollment card (register, then run). For a fleet, open the Activation keys tab, generate a reusable key (with an optional agent cap and expiry), pick the platform on its install page, download the agent package for Windows, Linux or macOS and run the install command shown there: it carries the key, registers the host and starts the service in one step. Windows fleets can use the standard MSI package with the mass deployment tooling they already run, and enrolled agents keep themselves current with one-click self-update from the console. Either way the host appears on the Assets screen with its first inventory within minutes and its score follows the first assessment. For the whole flow with screenshots, from the first activation key to the first verified patch job, follow the step by step setup guide. To add the network view, run a Sentinel Probe on each segment with the Sentinel Probes setup guide. For a site with a thin or restricted internet link, install a Sentinel Gateway with the Sentinel Gateways setup guide. The module activation checklist covers turning the module on.