Introduction
SEK Systems finds the vulnerabilities on your servers and workstations, shows which ones matter, and fixes them in a controlled way. A small agent on each host reports what is installed and what listens on the network. SEK Systems matches that inventory against new vulnerability data as it is published, ranks every finding by real risk, and lets you approve signed, typed fixes that the agent carries out within limits that you set on the host itself.
This documentation is written for the people who install and operate SEK Systems: system administrators, security officers and managed service providers.
Start here
- Install your first agent: from a fresh account to findings in about ten minutes.
- Requirements and network: supported systems and the outbound connections the agent needs.
- Agent command reference: every command you can run on a host.
- Local policy: the file on each host that limits what SEK Systems may change there.
- Dashboard guide: every page and button, and who may use it.
- Security model: what protects your hosts, in plain language.
How SEK Systems fits together
| Part | Where it runs | What it does |
|---|---|---|
Agent (sec-agent) |
on each Linux or Windows host | Collects the inventory, reports it, and carries out approved jobs within the local policy. |
Supervisor (sec-supervisor) |
on each host, next to the agent | Starts the agent from one of two slots and switches back if an update does not come up healthy. |
| Local policy | a file on each host | Sets the upper limit of what SEK Systems may do on that host. SEK Systems cannot widen it. |
| Console | https://console.sek.systems |
The dashboard: findings, hosts, plans, approvals, reports and settings. |
| Signing service | at SEK Systems, separate from the console | Signs a job only after the required approvals. The agent refuses anything that is not signed for it. |
Principles
- Outbound only. The agent opens no port on your host. It connects out over HTTPS to SEK Systems.
- Typed actions, no shell. SEK Systems can only ask for named actions such as "upgrade this package" or "restart this service". There is no way to run an arbitrary command.
- The host has the last word. Every job is checked against the local policy on the host, at the moment it runs.
- Four eyes. A change needs the approval of a second person, by default confirmed with a security key.
- Everything is logged. Each action lands in a tamper-evident audit log that you can read.
Tip
Looking for something specific? Press / to search, or open the list of all pages.