Security

Security model

An agent that can install updates and restart services has real power over your hosts. This page explains, without cryptographic detail, how that power is limited, and what you can check yourself. No system is perfectly secure; the design aims to make every misuse require several independent failures, and to make it visible.

#Outbound only, no open port

The agent opens no listening port on your host. It connects out to SEK Systems over HTTPS (port 443). Nobody can connect to the agent from the network, so there is no agent service for an attacker to attack.

The exception is a host you deliberately make a relay (sec-agent role allow relay); a relay listens on an internal address only, unless you explicitly allow more.

Check it yourself: ss -tlnp | grep sec (Linux) or Get-NetTCPConnection -State Listen (Windows) shows no listening socket of the agent.

#Two layers of encryption

1. TLS. The connection uses HTTPS / secure WebSocket. The agent checks the server certificate against the public web roots that are built into the agent, not against the certificate store of the host. A certificate that a middlebox or a tampered host store injects is not accepted.
2. A second, independent layer. Inside TLS, the agent and SEK Systems set up their own encrypted and authenticated channel, with keys that were exchanged at enrollment. Even someone who could read or break the TLS layer (for example a TLS-inspecting proxy, or a reverse proxy in the path) sees only encrypted messages, and cannot change or inject them.

On top of that, the messages that matter are signed: jobs by SEK Systems, results and reports by the agent.

#Per-agent identity

• Every agent gets its own identity at enrollment: its own key pair, created on the host. The private key never leaves the host.
• Where possible, that key is sealed to the machine (TPM, or Windows DPAPI), so a copy of the files does not work on another computer.
• The identity is valid for 30 days and is renewed automatically with new keys halfway through. A stolen key therefore stops working on its own.
• Enrollment uses a one-time token with a short validity (the installation line: one host, one hour). A used or expired token is worthless.
• An agent can be revoked in the console at any moment; SEK Systems refuses its connection from then on.

#Only signed, typed jobs

• The agent only executes jobs signed with the key of your environment. A job is signed for one host, has a validity window and a sequence number, and cannot be replayed or redirected to another host.
• Each job is one typed action with checked parameters: upgrade this package, restart this service, set this firewall rule. The agent itself implements each action with the system's own tools.
• There is no shell. No action runs an arbitrary command or script, and the local policy refuses allow_script = true. Not even SEK Systems can send a command line to your host.

#The host has the last word

Every job is checked against the local policy on the host, at the moment it runs. The policy is a file that only root or an Administrator can change, and SEK Systems cannot widen it. It sets which actions are allowed, which packages and services are off-limits, when changes may happen, and how many per hour.

Check it yourself: sudo sec-agent policy.

#Four eyes and security keys

• A change needs the approval of a second person: the requester can never approve their own plan. This is checked by the console, the server and the signing service.
• By default an approval needs a security key or passkey (FIDO2/WebAuthn): phishing-resistant, and bound to the real SEK Systems address. Owners can relax this; the approval policy and each plan show what applies.
• Owners and admins must use a security key at every sign-in by default.
• An approval is bound to a fingerprint of the exact plan. Changing the plan afterwards voids it.
• A pace limit caps how many hosts can receive a change per hour and per day, so a mistake or a hijacked account cannot hit everything at once.

#A tamper-evident audit log

Every action is recorded in the audit log: who, what, when, on which host, with which result. Each record carries the hash of the previous one, so removing or changing a record breaks the chain. The database refuses updates and deletions of audit records. Actions of SEK Systems support in your environment appear there too, as "SEK Systems support".

#Tenant isolation

Your environment's data is separated from other environments in the database itself: every query runs with the identity of one environment, and the database only returns rows of that environment (row-level security). The signing keys are per environment, so a job for one environment can never be valid in another. A member sees only the environments they belong to; the console never shows that other environments exist.

#Kill switch

One owner or admin can stop all changes at once with the kill switch. The agents receive a signed message, check it themselves and refuse new jobs until release. Reporting continues.

#Signed updates

The agent only installs updates whose release metadata is signed and whose program matches the published checksum, and it never downgrades. A new version runs as a trial and is rolled back automatically if it does not come up healthy. See Agent updates. On Windows, the installer also checks the Authenticode signer.

#If SEK Systems itself were compromised

We design for this case too. Suppose an attacker gained control over parts of SEK Systems:

• The console and server cannot sign jobs. Signing is done by a separate signing service that holds the keys. It refuses jobs beyond the pace limit and the agent-count limit, so even a misused server cannot change all hosts at once, and it does not sign while the kill switch is on.
• Every job is still bound by the local policy of each host. An attacker can do no more than your policy allows: nothing on observe hosts, only dry runs on dry_run_only hosts, never a package in deny_packages, never outside local_windows.
• There is no command execution to abuse: only typed actions.
• Agent updates must match signed release metadata.
• Your audit log shows every job that was signed and executed.

What this means in practice: for hosts where even a misused update is unacceptable, use profile = "observe" or dry_run_only = true, or narrow allowed_actions, deny_packages and local_windows. The local policy is the one control that is fully in your hands.

#What you can check yourself

Found a security problem? Contact SEK Systems through the contact details in your agreement.