From Zero Visibility to a Managed Fleet: Building an Endpoint Security Program from Scratch

Starting With Discovery, Not Assumptions

Before deploying any security tooling, the team ran a network discovery pass using Wireshark to map out what devices actually existed on the network. This is a step that's easy to skip when there's pressure to "just get the agents installed," but it matters: you can't protect what you haven't found, and you can't claim full coverage without first knowing what "full" is. That discovery work fed into a consolidated asset inventory spanning multiple endpoints, each tracked with its OS, its management tooling, and its IP address.

Laying the Network Foundation With Tailscale

Perimeter network exposure like RDP is a risk which shaped an early architectural decision: rather than opening more inbound ports to manage the endpoints, I built a private Tailscale tailnet. Every endpoint got a stable, authenticated address independent of its underlying network. Meaning network traffic no longer depends on the public internet, or expands the attack surface.

The rollout was straightforward by design: install the Tailscale client, enable the daemon, authenticate the device, and confirm its tailnet IP. For endpoints that needed hands-off provisioning, the team used reusable, time-boxed auth keys generated from the admin console rather than manual interactive logins, a small choice that matters at scale, since it keeps onboarding repeatable without leaving long-lived credentials lying around.

Establishing the Vulnerability Baseline With Wazuh

With connectivity in place, I deployed Wazuh agents to all endpoints, turning on File Integrity Monitoring, the vulnerability detection module, MITRE ATT&CK tactic mapping, and CIS Security Configuration Assessment (SCA) scoring. OS-specific rule sets were configured across Windows, Linux, and macOS to keep detection logic relevant to each platform rather than relying on one generic ruleset for everything.

The first scan told a blunt story. The Ubuntu host came back with 163 critical and 1,036 high severity vulnerabilities, a backlog that had clearly been accumulating for a long time in an environment with no prior scanning history. The Windows workstation carried a smaller but still meaningful load: 2 critical and 49 high findings. The Kali box, by contrast, came back clean across the board. CIS SCA benchmark scores landed at 44% for Ubuntu and 46% for Kali, both well below any reasonable target, and a clear quantitative anchor for the hardening work still ahead.

This is the value of a real baseline, it replaces "we assume things are risky" with a number the team can be held to, and a number that future scans can be measured against.

Centralizing Patch Management With Action1

Vulnerability visibility is only half the equation, the other half is doing something about it. I deployed Action1 across endpoints to centralize patch visibility and deployment. It's worth noting my choice to keep Action1's findings separate from Wazuh's rather than merging the two into one number. Action1 detects missing updates directly from vendor patch metadata, while Wazuh's vulnerability module matches installed package versions against CVE databases. Two different methods that can legitimately disagree. Reporting them side by side, rather than blending them into a single misleading figure, is a good discipline that's easy to skip.

On top of the tooling, the team stood up actual governance. A documented SLA policy tying remediation timelines to severity:

• Critical (CVSS 9.0–10.0):

  24-hour remediation SLA, immediate CISO notification and endpoint isolation if breached

• High (CVSS 7.0–8.9):

  3-day SLA, daily status updates if breached

• Medium (CVSS 4.0–6.9):

  7-day SLA, weekly reporting

• Low (CVSS 0.1–3.9):

  30-day SLA, monthly review with a 90-day risk-acceptance window

An automated "Deploy Updates" policy was also configured in Action1 for critical patches with auto-approval, turning the 24-hour critical SLA from a promise on paper into something the tooling actually enforces.

Before / After Posture Scorecard

The Windows workstation shows the clearest before/after movement so far: critical findings dropped from 2 to 1, and high-severity findings fell from 49 to just 2, with medium/low findings cleared entirely. Action1 flagged 22 missing updates across endpoints, and one requiring a reboot to complete.

The Ubuntu host is a different story, and I was deliberate about not dressing that up. The scorecard still shows 163 critical and 1,036 high findings identical to baseline, not because nothing happened, but because a patch deployment policy was configured and an update cycle was run, yet a post-patch Wazuh re-scan seem to have a lot of false positive. That's a small editorial choice with an outsized signal. It's tempting, in any status report, to let a configured policy imply a fixed problem. Separating "we deployed the fix" from "we confirmed the fix worked" is the difference between a security program that reports activity and one that reports outcomes.

Conclusion

Stripped of tool names, the sequence here is a template worth reusing on any greenfield environment:

1. Discover before you defend.

   You need an inventory before "coverage" means anything.

2. Fix the transport layer first.

   A private, authenticated overlay network (Tailscale, in this case) removes whole categories of exposure before a single vulnerability gets patched.

3. Baseline before you remediate.

   Numbers you can't cite later aren't a baseline.

4. Separate detection methods instead of merging them.

   Different tools measure different things; blending their output produces false confidence.

5. Write SLAs down, then automate them.

   A policy that only lives in a document doesn't hold anyone accountable.

6. Report what's actually confirmed.

   An unverified fix and a verified one are not the same status, even if they'll eventually look identical on a dashboard.