Docs / Enterprise
NIST SP 800-53 mapping
This maps the controls a Gardience install helps you meet, for your System Security Plan (SSP) or an assessor. It is a self-assessment by Bouziden Management LLC, not a third-party attestation. Gardience is software you run on your own server, so most controls are shared: Gardience supplies the mechanism and you configure, operate and document it.
Legend: Provides = Gardience implements the mechanism. Supports = Gardience produces evidence or tooling for a control you own. Customer = outside Gardience; listed so the SSP has no gap.
Access control (AC)
| Control | Role | How |
|---|---|---|
| AC-2 Account management | Provides | Users come from your directory (LDAP, OIDC or SAML SSO) or a local file. Removing a user ends their open console sessions at once (gardience user del; directory and SSO users removed at the source lose access within the 1-hour directory session limit, or at once with gardience user signout NAME) and rejects their API keys at once (removed_users.json). API keys expire (1 to 365 days, default 90). |
| AC-3 Access enforcement | Provides | Every action passes through Salt's publisher ACL and Gardience's governed roles (gdn: grants). Read-only roles are limited to inventory reads. Vault secrets are scoped to node lists and refused outside them (403). |
| AC-5 Separation of duties | Provides | Runbooks can carry a two-person approval step; the person who launches a run cannot approve it. Baseline or reboot pushed to more than one node from the dashboard needs a second person. Clearing an audit tamper alarm takes two people. Exception: admins keep direct Salt access as an audited break-glass path, which approvals do not cover. |
| AC-6 Least privilege | Provides | Built-in roles (admin, approver, operator, help desk, viewer, scanner, automation); every role, admins included, gets only governed actions, never raw Salt rights; root on the server can open a time-limited, audited break-glass account (gardience breakglass on). Inside the server, the web service runs as a non-root user, and each playbook run gets its own unprivileged user, process limit and temporary directory. |
| AC-7 Unsuccessful logon attempts | Customer | Lockout is enforced by your directory or identity provider. |
| AC-12 Session termination | Provides | Local-account sessions expire after 8 hours (session_hours, 1 to 24); directory and SSO sessions after 1 hour (directory_session_hours); sign-out ends the session in every tab; closing every console tab ends it after a minute; gardience user signout ends a person's sessions on demand. |
| AC-17 Remote access | Provides | The console is reachable only over HTTPS. salt-api, the Gardience service and the runner are not published outside the server (checked by nmap in every release test). |
Audit and accountability (AU)
| Control | Role | How |
|---|---|---|
| AU-2, AU-3 Event logging and content | Provides | Sign-ins (local, LDAP and SSO, successful and failed), commands, approvals, changes and admin actions are logged with who, what, target and when, including actions on the Salt master itself (runner and wheel calls that can change something, and every agent key accepted, deleted or rejected). Routine read-only scans are logged with a node count and a SHA-256 of the node list rather than every name. |
| AU-4, AU-6 Storage and review | Supports | Forwarding to your SIEM over syslog. Over TCP or TLS a delivery position is kept per destination, so an outage or a change of destination leaves no gap; over UDP entries can be lost in transit. Very large entries are forwarded with a count and hash of their node list. No automated retention: keep or archive sealed log segments yourself. CSV export and an evidence pack for review. |
| AU-5 Response to logging failures | Provides | If the log cannot be written (disk full, I/O error) the partial entry is removed, the console shows the failure and Gardience refuses changes until it can write again. A broken or tampered log raises a lasting alarm (console, readiness check, Prometheus) until one admin reviews it and a second admin or approver confirms. A shipped alert rule pages on it. |
| AU-9 Protection of audit information | Provides | Each entry is chained with a keyed hash (HMAC) and the chain head is checkpointed with a separate keyed MAC, so editing, deleting or reordering entries is detected. Verification runs at startup and on a schedule. |
| AU-10 Non-repudiation | Supports | Entries record the identity from the verified session, not from the request. Full non-repudiation needs signing by an external timestamp authority (customer). |
| AU-11 Retention | Customer | Gardience keeps log segments until you remove them; set retention in your SIEM. |
| AU-12 Audit record generation | Provides | Logging is always on and cannot be disabled from the console. |
Configuration management (CM)
| Control | Role | How |
|---|---|---|
| CM-2, CM-6 Baseline and settings | Supports | Scans each Windows and Linux node against the shipped baseline controls and reports drift per node, with evidence. |
| CM-3 Change control | Provides | Change windows and host locks apply to console runbooks, dashboard fixes, workflows, schedules, API runs, held work released when a node reconnects, and drift auto-correct. Exceptions: an admin's audited emergency override, an admin's direct (break-glass) Salt session, which is audited but not window-checked, and the drift reactor's restart of a stopped watched service, which Salt runs at once. Each change is logged. |
| CM-7 Least functionality | Provides | The server publishes only HTTPS and the two Salt agent ports. |
| CM-8 Inventory | Supports | Live node inventory with OS, groups and last-seen time; CSV and API export. |
| CM-14 Signed components | Provides | Upgrades verify an Ed25519 signature and file hash before anything runs, and refuse older versions. |
Contingency planning (CP)
| Control | Role | How |
|---|---|---|
| CP-9 Backup | Provides | gardience backup takes a consistent snapshot including Salt keys, encrypted when given a passphrase file (with a keyed integrity code checked before decrypting) and always checksummed; restore refuses an archive without its checksum unless told otherwise. |
| CP-7, CP-10 Alternate site, recovery | Provides | Warm standby: encrypted sync to a second server, automatic agent failover, gardience promote, and fencing so a returning old primary cannot run alongside it. Procedure and drill results in DR-RUNBOOK.md. |
Identification and authentication (IA)
| Control | Role | How |
|---|---|---|
| IA-2 Identification and authentication | Provides | Every request needs a session token or API key. |
| IA-2(1), (2) Multi-factor | Supports | MFA is enforced by your identity provider through OIDC or SAML sign-in. |
| IA-5 Authenticator management | Provides | API keys are stored hashed, shown once, expire and can be revoked. Agent enrollment tokens expire and can be revoked. |
Risk assessment, acquisition, integrity (RA, SA, SI, SR)
| Control | Role | How |
|---|---|---|
| RA-5 Vulnerability scanning | Provides | Every release scans the pinned Python dependencies with pip-audit and the three images it builds with Trivy (no fixable high or critical allowed), and the code with Bandit (no high-severity finding allowed). |
| SA-11 Developer testing | Provides | Every release runs the release check: unit tests, end-to-end lab, enrollment on Windows and Linux, isolation, stress, 10,000-node scale reads, offline install, HA drill and the security test (OWASP ZAP, nuclei, testssl.sh, nmap). See SECURITY-TESTING.md. |
| SI-2 Flaw remediation | Provides | Severity-based fix targets in SUPPORT.md; signed upgrades with automatic rollback. |
| SI-7 Software integrity | Provides | Signed releases, pinned image digests, signed upgrade path. |
| SR-4 Provenance | Supports | Offline (air-gapped) bundles ship a CycloneDX software bill of materials for each image, built from the exact images in the bundle; the same files are published with each release. |
System and communications protection (SC)
| Control | Role | How |
|---|---|---|
| SC-8 Transmission confidentiality | Provides | Console: TLS 1.2 and 1.3, AEAD ciphers only. Agents: Salt's encrypted transport (AES with per-session keys). |
| SC-12, SC-13 Key management, cryptography | Provides | AES-256-GCM vault key, Ed25519 release signing, HMAC-SHA256 audit chain. Not a FIPS 140-validated module. |
| SC-28 Protection at rest | Provides (secrets) / Customer (disk) | Vault secrets and standby backups are encrypted; other backups are encrypted when you give them a passphrase file. Note that anyone allowed to run commands on a machine a secret is scoped to can read it there. Full-disk encryption of the server is yours. |
| SC-39 Process isolation | Provides | Each playbook run executes as its own unprivileged user with resource limits and is killed in full when it ends. |
Not covered
FIPS 140 validation, a third-party penetration test, SOC 2 and FedRAMP authorization are not in place today. Ask us for current status.