Six Agents on Every Server

In the first post I wrote about the patching problem that started all this. What I left out is how quickly it grew.

I wanted patching that ran on its own. Within a few weeks I had a list of other things that obviously belonged next to it.

Six agents, four consoles

At the time I was running six agents on every server: monitoring, MFA, management and patching, vulnerability scanning, ransomware protection and EDR. On top of that I had a password tool, network discovery and an ITSM, all separate. None of them shared anything useful with the others.

Why?

The management tool could already run anything as SYSTEM, and it already had scripting. It could easily have gone one step further and automated the checks I was doing by hand. It didn’t. Things move slowly in this part of the industry. We once waited more than 90 days for a fix to a bug in the reporting engine. A reporting bug.

So I started building Cadres, beginning with patching. It quickly became clear patching wasn’t enough on its own. Patching is useless without host management, host management is incomplete without remote control, and remote control without session recording is a security hole. You can see where this goes.

I kept going. Anything I’d found useful went in, on the same data model, and any workflow I’d been doing by hand became something the platform does.

“Good enough” at some things

The obvious objection is that we’ll end up average at everything. We won’t be the best at everything, and we’re not trying to be. We aim to be excellent at the things that matter most and good enough at the rest. Good enough inside a platform where everything is connected beats best in class in a tool that can’t talk to anything.

What you see when you open a host

I built host management around one test: a server admin should never need to leave the console. Open a host and you get:

• Live health metrics for CPU, memory, disk and network
• Network performance including latency, jitter, packet loss and interface status
• Configuration covering OS details, hardware and system properties
• Out-of-band management for iDRAC, iLO and IPMI
• Services you can start, stop, restart, enable or disable
• Running processes you can inspect or kill
• Local users and groups on the host
• Security status including certificate expiry and vulnerabilities
• Software deployment with license compliance and usage tracking
• Event and log viewer with filtering and search
• Diagnostics run from the host itself: ping, traceroute, nslookup, netstat and port checks
• SSH and PowerShell in the browser
• Remote control in the browser. On Windows the agent keeps RDP disabled when nobody is connected, which your security team will like
• File browser with upload and download

All of it runs through the agent. The backend is SaaS and has no network access to your hosts; the agent does the work and the platform tells it what to do.

You don’t need the MFA agent

Remember the MFA agent? It’s gone. You already sign in to Cadres with MFA, so when you connect to a host through it you’ve already done the second factor. There’s no need for another product on RDP to tick an audit box.

Turning features off

For sensitive workloads, any of these features can be switched off per host or per policy. Not every server needs a file browser and not every team needs a remote console.

Session recording

Everything in the platform is logged, and every SSH, PowerShell and remote control session is recorded in full. If something goes wrong you can see who did what, when, and where they clicked.

It also helps with audits. When an auditor asks who accessed a server and what they did, you don’t pull logs from four systems and line up timestamps. You open the recording and press play.

Next

Managing local users and groups on a host turned out to lead somewhere bigger. That’s the next post.

If you’re running several agents, tools and dashboards for what should be one job, start a trial.